How severe is GHSA-jjgp-whrp-gq8m?

No CVSS score has been assigned to GHSA-jjgp-whrp-gq8m yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-jjgp-whrp-gq8m?

GHSA-jjgp-whrp-gq8m affects the following packages: in-toto (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-jjgp-whrp-gq8m?

No patched version of in-toto has shipped for GHSA-jjgp-whrp-gq8m yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

How do I detect GHSA-jjgp-whrp-gq8m in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for in-toto. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-jjgp-whrp-gq8m if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-jjgp-whrp-gq8m?

O3 pinpoints whether GHSA-jjgp-whrp-gq8m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-jjgp-whrp-gq8m actively exploited in the wild?

No public exploit code has been indexed for GHSA-jjgp-whrp-gq8m yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-jjgp-whrp-gq8m published, and has it been updated?

GHSA-jjgp-whrp-gq8m was published on May 11, 2023 and was last updated on November 30, 2024. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-jjgp-whrp-gq8m

in-toto: PGP trust model not (fully) considered

Published

May 11, 2023

Updated

Nov 30, 2024

Affected

1 pkg

Patched

None yet

Exploits

None indexed

Blast Radius

1 pkg affected

🐍in-toto

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Impact

This security advisory lists multiple concerns about how in-toto uses PGP keys. The findings are aggregated here, because they are all eligible to the same mitigation strategy. Note that the findings are rated with different severities (see inline) and the highest score was chosen for this advisory:

PGP Key Creation Time Not Validated (severity: low) in-toto does not check, if the validity period of a PGP Key (starting with the key creation time) is in the future, when copying the key from GnuPG to a layout, or when verifying signatures. A validity period in the future is usually a sign of a wrong system clock, meaning it can’t be trusted for verifying the validity period. A MITM attacker who is able to manipulate delivered software products might also be able to control the system time by manipulating NTP. In a scenario where an attacker gained control over two expired subkeys with no overlapping validity period, the attacker could set the system time to a time before the validity period of either key, resulting in both keys being accepted.
PGP Key Revocation Not Considered (severity: medium) in-toto does not check PGP revocation signatures, when copying the key from GnuPG to a layout, or when verifying signatures. This means that a key may still be accepted in signatures, even if it has been revoked in GnuPG.
PGP Key Usage Flags Not Considered (severity: low) in-toto does not check PGP usage flags, when copying the key from GnuPG to a layout, or when verifying signatures. This means that at a key may still be accepted in signatures, even if it is not permitted to sign data as per its key usage flags.

Security auditors recommend to verify these properties at signature verification time.

However, this is not planned, as in-toto does not rely on PGP’s trust model, because it should not be required to consult with a separate PKI/web-of-trust at verification time. Instead the project owner establishes ultimate trust by adding a PGP public key to a layout, and thus is responsible for its validity, and also to revoke the layout, if the key is no longer trusted. The same is true for PGP public keys used to verify a layout.

The preferred mitigation strategy is to verify these properties when exporting a public key from GnuPG, and to clarify usage documentation that no verification against the PGP trust model is performed afterwards.

References

"Handle GPG revocation signatures" -- https://github.com/secure-systems-lab/securesystemslib/issues/190
"inconsistent use of GnuPG" -- https://github.com/in-toto/in-toto/issues/569

Affected Packages

1 total

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`in-toto`	all versions	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for in-toto. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of in-toto has shipped for GHSA-jjgp-whrp-gq8m yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-jjgp-whrp-gq8m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-jjgp-whrp-gq8m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact This security advisory lists multiple concerns about how in-toto uses PGP keys. The findings are aggregated here, because they are all eligible to the same mitigation strategy. Note that the findings are rated with different severities (see inline) and the highest score was chosen for this advisory: - **PGP Key Creation Time Not Validated** (severity: low) in-toto does not check, if the validity period of a PGP Key (starting with the key creation time) is in the future, when copying the key from GnuPG to a layout, or when verifying signatures. A validity period in the future is

O3 Security · Impact-Aware SCA

Is GHSA-jjgp-whrp-gq8m in your dependencies?

O3 detects GHSA-jjgp-whrp-gq8m across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works