# Evidence-Chain Integrity Assessment — CVD-2026-0012 **Incident:** CVD-2026-0012 — path-traversal in artifact-serving endpoint **Organisation:** Meridian Systems **Prepared by:** Marc Dubois, Head of Security Engineering (Security Lead) **Stage:** 3 — Contain (`contain-evidence-chain` task template) **Date:** 2026-04-08 **Classification:** Internal — incident-restricted. *All entities, data, and findings are fictional.* --- ## What the exposed token could reach The credential exposed was the compliance-platform service-account token `svc-meridian-sync@compliance`, stored as a plaintext build-pipeline variable in the CI/CD pipeline runner running on Meridian's staging cloud subscription. The token held the following permission scopes on the compliance platform at the time of exposure: | Scope | Operations permitted | |---|---| | `evidence:read` | Download any evidence artefact in the Meridian workspace | | `evidence:write` | Upload evidence artefacts and overwrite existing versions | | `control:read` | Read control assessments, audit questions, and framework mappings | | `report:generate` | Trigger evidence-summary report generation and download the output | | `log:read` | Read the compliance platform's own audit log | The `evidence:write` scope is the critical risk: an adversary with this token could have replaced stored evidence files with modified versions. Overwrite operations that match the expected file name and structure would not trigger an alert under the compliance platform's default configuration. --- ## Exposure window The vulnerable endpoint was introduced in Meridian Systems version 3.4.0, shipped 2026-03-12. The endpoint was taken offline 2026-04-08 14:45 UTC as an emergency containment measure and the token was revoked 2026-04-08 15:30 UTC. The exposure window is **27 days** (2026-03-12 to 2026-04-08). --- ## Audit log analysis The compliance platform's audit log was exported in full for the exposure window. 114 API calls were made using the `svc-meridian-sync@compliance` token during the 27-day period. - **111 calls — confirmed Meridian automation.** Cross-referenced against the CI/CD pipeline run history; timestamps and operation types match exactly. All are evidence-read or evidence-write operations consistent with the scheduled sync job. - **3 calls — NOT attributable to Meridian automation.** All three occurred on 2026-04-07 between 03:21 and 03:44 UTC — 2 hours and 22 minutes before Meridian's scheduled 06:00 sync: | Time (UTC) | Operation | Resource | HTTP result | |---|---|---|---| | 03:21:14 | `evidence:read` GET | `controls/A.5.7/evidence-2026-03-28.pdf` | 200 OK — file downloaded | | 03:38:02 | `evidence:read` GET | `controls/A.8.12/evidence-2026-03-30.pdf` | 200 OK — file downloaded | | 03:44:58 | `evidence:read` GET | `controls/A.8.20/evidence-2026-04-01.pdf` | 200 OK — file downloaded | No write, delete, or report-generation operations appear in the unexplained window. The access pattern — three targeted GETs on evidence files uploaded within the preceding 10 days — is consistent with the researcher's reported proof-of-concept script, which automated targeted evidence retrieval to demonstrate the token's scope after extraction. **Audit log caveat:** The compliance platform records object-read operations with one-minute timestamp resolution. It is theoretically possible that an operation performed within the same minute as a legitimate Meridian sync could be masked. The probability is low (Meridian's sync runs at 06:00 UTC; the anomalous access was at 03:21–03:44 UTC), but it cannot be excluded with certainty. This caveat is reflected in the provisional-trust classification below. --- ## Evidence verified intact Hash verification was performed by computing SHA-256 over each evidence file as stored in the compliance platform and comparing it against an independently retrieved copy produced directly from the originating system (bypassing the compliance platform entirely): - **47 control families not accessed in the three anomalous calls:** All hash comparisons confirmed. No modification detected. - **The 3 accessed files:** Hash comparisons confirmed against the version in the compliance platform's own version history immediately before and immediately after the anomalous window. No file modification was detected. The current content matches the content that existed before the anomalous access. --- ## Evidence declared provisionally untrusted The following three artefacts are declared **provisionally untrusted** pending re-attestation: | Control | Artefact | Reason for provisional classification | |---|---|---| | ISO 27001:2022 A.5.7 — Threat intelligence | `controls/A.5.7/evidence-2026-03-28.pdf` | Accessed at 03:21 UTC by the unexplained token use. Hash confirms no modification to stored bytes, but read access with an `evidence:write`-capable token cannot exclude an unlogged in-session interception or a substitution not yet visible in the version history. | | ISO 27001:2022 A.8.12 — Data leakage prevention | `controls/A.8.12/evidence-2026-03-30.pdf` | Accessed at 03:38 UTC. Same basis as A.5.7. | | ISO 27001:2022 A.8.20 — Network security | `controls/A.8.20/evidence-2026-04-01.pdf` | Accessed at 03:44 UTC. Particularly sensitive: this control's evidence covers network segmentation directly relevant to the incident's own attack surface. | **Provisionally untrusted does not mean modified.** Hash verification shows no modification. The classification reflects that (a) the audit trail cannot exclude unlogged access modes, and (b) these three artefacts were produced and stored by the system that was also the subject of the compromise. --- ## Re-attestation requirements Re-attestation for the three provisional artefacts requires all four of the following: 1. **Independent re-production.** The evidence must be re-produced from the primary source system by the named control owner. The re-produced file must not pass through the compliance platform at any point in its production. Dated after the endpoint was taken offline and the exposure window closed (2026-04-08 14:45 UTC). 2. **Dual sign-off.** The control owner and Marc Dubois (Security Lead) must both sign that the re-produced evidence accurately reflects the control state as of the original evidence date and that the re-production method was independent of the compromised path. 3. **Chain-break documentation.** The re-attestation record must explicitly state that the previous evidence was declared provisionally untrusted under CVD-2026-0012 and the date of that declaration. 4. **Compliance-platform re-upload.** The re-attested version replaces the provisional artefact. The superseded version is retained in version history with the filename suffix `[SUPERSEDED-CVD-2026-0012]`. **Target:** re-attestation completed before Stage 5 (Recover) gate sign-off. --- **Actions taken in this stage:** - Exposed token `svc-meridian-sync@compliance` revoked: 2026-04-08 15:30 UTC - Replacement token minted with reduced scope (read-only, IP-restricted): 2026-04-08 15:45 UTC - Compliance-platform session tokens issued to Meridian staff during the exposure window invalidated: 2026-04-08 15:50 UTC **Prepared by:** Marc Dubois, Head of Security Engineering **Reviewed by:** Lena Hartmann (IC), 2026-04-09 07:30 UTC **Status:** Final — Stage 3 (`contain-evidence-chain`) gate signed.