An AI-DLC report could rewrite its own findings

A traceability report is supposed to make a project's evidence easier to inspect. In the vulnerability AWS disclosed on November 2, 2026, that report could also change what a reviewer saw. CVE-2026-120497 affects the HTML output of the old aidlc-traceability command line tool. Someone who can change a project's artifact titles or descriptions could cause a script to run when another person opens a report generated by an affected copy. [1] [2]

Where a title stops being just a title

The tool was part of AWS AI-DLC Workflows. It reads project artifacts and produces a traceability matrix, a way to follow the connections between work products. For example, a reviewer might use a matrix to see whether a requirement has a related implementation and where evidence is missing. The HTML version embeds artifact data in the page so that the report can use it when opened in a browser. [1] [2] [3]

The weakness was in that embedding step. A browser reads the surrounding HTML as well as the data inside it. With the affected generator, a crafted field could make the browser think the embedded script had ended, then introduce new content that the browser would run. The field persists in the project and takes effect when the report is opened, which is why this is called stored cross-site scripting. The patched generator neutralizes the closing sequence in its output so project text stays inside the intended script section. [2] [3]

The maintainers say a script running in the report can change the displayed coverage and gaps or read information already in the report, such as local file paths. They say this issue does not provide access to other local files or credentials. It does not require AWS credentials or the tool's AI mode to trigger. The relevant chain is a modified artifact, a vulnerable generator, and a person opening its HTML output. [2]

The generator and the report have separate lifetimes

AWS identifies aidlc-traceability 0.1.0 and later revisions before commit 96cf0ea as affected. The fix was merged July 3, 2026. The CLI was removed from the original repository on July 16 and is no longer maintained there. AWS advises removing older local copies or updating them to include the fix, and checking forks and derivatives. AWS points to a separately maintained replacement that runs within an AI coding assistant; it is a different implementation. [1] [2] [3] [4]

Until an affected copy is removed or updated, the vendor advises against opening its HTML reports from untrusted projects. It suggests using the tool's Markdown output or generating reports from artifact files you control. The November notice is useful even if the original repository no longer contains the CLI: a checkout, a build image, or a fork can carry the old code long after it has disappeared upstream. [1] [2]

A newer generator also does not change an HTML file that was saved last month. Imagine a team keeping reports alongside release signoffs. A dashboard in an old attachment might look just like the one from today's patched generator. If that older artifact came from an untrusted project, it is a reason to revisit the underlying evidence and produce a fresh report from the appropriate inputs, without opening the suspect HTML to see what it says.

A polished report is still a view of the evidence

Suppose a hypothetical reviewer sees a green coverage result for a critical requirement. The decision that matters is whether the requirement actually has a supporting test or implementation. A traceability report can point to that evidence quickly. For a consequential signoff, being able to follow the link back to the project revision is more useful than the color on the report.

The same question matters at a handoff. When a report arrives with no clear origin, the team inheriting it needs to know which project snapshot it describes and what produced it. A clear link to those inputs makes a review repeatable even if the old report has to be retired.

For teams still using this workflow, we would keep the generator revision alongside the source revision for each report used in a decision. That makes it easier to tell which reports can be regenerated and which should be set aside. The advisory describes what the flaw makes possible; it does not say that a particular report or approval was tampered with. [1] [2]