GHSA-pmwq-pjrm-6p5r

What it actually does

The flaw is a semantic mismatch between in-toto implementations when evaluating glob character-class negation in artifact rules. in-toto-python interprets `!` as the negation operator inside character classes, while in-toto-golang historically used `^`. If the same layout and attestation bundle are verified by different implementations at different stages of a supply-chain pipeline, an artifact rule may match a different set of files depending on which verifier is used. This can cause expected or disallowed artifacts to be incorrectly accepted, rejected, or ignored, weakening the integrity guarantees of in-toto policy enforcement.

Why it matters to the business

Organizations that rely on mixed in-toto implementations in build, release, or verification workflows could make inconsistent trust decisions about the same software artifacts. In practical terms, a build artifact that should have been blocked may pass one stage of the pipeline, creating risk of unauthorized, incomplete, or tampered artifacts being promoted. The issue has moderate severity, is not listed in CISA KEV, is not associated with ransomware use, and has no reported exploit maturity, but it is important for software supply-chain environments because policy inconsistencies can undermine release assurance.

How an attack unfolds

An attacker would first need influence over artifact names, generated files, attestations, layout authoring, or a build step that produces artifacts evaluated by in-toto rules. They would identify a pipeline where one stage creates or tests a layout using one in-toto implementation and another stage verifies or enforces it using the other implementation. The attacker then crafts artifact names or rules involving character classes with negation, such as patterns whose behavior differs depending on whether `!` or `^` is treated as the negation operator. If the pipeline relies on the weaker or unintended interpretation at a critical enforcement point, the attacker may cause an artifact to be included, excluded, or considered compliant contrary to the layout author’s intent. Successful exploitation is highly context-dependent and generally requires a mixed-implementation pipeline plus control over relevant artifact names or policy inputs.

How to fix it

Standardize on a single in-toto implementation across layout creation, build execution, attestation generation, and verification wherever possible. Review layouts for glob character classes that use negation and rewrite them to avoid implementation-specific ambiguity, especially patterns containing `[!...]` or `[^...]`. Where mixed implementations cannot be avoided, add compatibility tests that verify the same layout and attestation bundle with every implementation used in the pipeline and fail closed on any difference in matched artifacts or verification results. Upgrade in-toto-golang and in-toto-python to versions that include the upstream advisory fix or harmonized behavior when such fixed versions are available through the relevant package manager or project release channel. Treat any layout change involving artifact-rule globbing as a security-sensitive change requiring review.

How to confirm the fix worked

Confirm which in-toto implementations are used in each stage of the software supply-chain workflow. Inventory layouts and artifact rules for glob character-class negation syntax, especially `[!...]` and `[^...]`. For each affected layout, run verification with both in-toto-python and in-toto-golang against the same artifact set and attestation bundle, then compare matched artifacts and verification outcomes. The fix or mitigation is validated when all active pipeline stages use one implementation or produce identical rule-matching and verification behavior across implementations, and when ambiguous glob patterns have been removed or explicitly tested.

Typical attack path

1. Identify a build or release pipeline that uses both in-toto-python and in-toto-golang to process the same layout and attestation bundle.
2. Review or infer artifact rules that contain glob character classes using `!` or `^` negation syntax.
3. Create or modify artifact names so that they match under one implementation’s glob semantics but not the other’s.
4. Trigger the build, attestation, or verification workflow with the crafted artifact set.
5. Rely on inconsistent verifier behavior to bypass an intended artifact rule, omit an artifact from scrutiny, or have an unintended artifact accepted.
6. Attempt to promote the resulting artifact through later release, deployment, or distribution stages.

How to detect it

This issue is unlikely to produce conventional host or network indicators. To assess possible prior exploitation, review source-control history for in-toto layout changes involving artifact-rule glob patterns, especially character classes using `!` or `^`. Compare historical build and verification logs from stages using in-toto-python versus in-toto-golang and look for inconsistent pass/fail outcomes, unexpected artifact inclusion or exclusion, or artifacts promoted after one verifier accepted them while another would not. Re-run historical high-value release bundles through both implementations and diff the matched artifact sets and verification results. Investigate suspicious artifact names crafted around single-character differences, unusual punctuation, or names designed to fall inside or outside negated character classes. Also review CI/CD logs, release approval records, provenance attestations, and artifact repository metadata for unexpected files that bypassed intended in-toto rules.

What your security team should do

• Prioritize review of release, signing, provenance, and deployment pipelines that use in-toto for artifact integrity decisions.
• Determine whether both in-toto-python and in-toto-golang are used against the same layouts or attestations in any workflow.
• Search layouts for artifact rules containing glob character-class negation, particularly `[!...]` and `[^...]`, and refactor ambiguous patterns.
• Adopt one in-toto implementation consistently across layout authoring, execution, attestation, and verification where operationally feasible.
• Add regression tests that compare verification results across implementations before accepting layout or tooling changes.
• Require security review for changes to in-toto layouts, artifact rules, attestation generation, or release verification logic.
• Monitor upstream in-toto advisories and package repositories for fixed releases and upgrade promptly when available.