Summary
commonground-api-common unexploitable privilege escalation in JWT authentication middleware
Will be fixed in 1.12.2
Workarounds
None needed. But be careful when updating PyJWT. Check that the used PyJWT has no algorithms specified with a name in "", "HS25", "HS2", "HS", "H", or that those algorithms are acceptable.
Details
The header and payload of JSON Web Tokens (JWTs) are cryptographically signed with an algorithm. A JWT has a header field alg that specifies the algorithm used in the signature.
The vng-api-common.middleware.AuthMiddleware uses PyJWT to check the validity of JWT and indicates it should be "HS256", otherwise an attacker could construct a token with a cryptographically weak token. It should indicate this with a list of acceptable algorithms ["HS256"], but instead the string "HS256" is passed to PyJWT. PyJWT does not check the type of the argument and checks if the alg string in the header exists in the acceptable algorithms value with the in operator. Any substring of "HS256" passes this in check. It is not exploitable because there is no such substring in de set of algorithms PyJWT supports.
Impact
This is a privilege escalation vulnerability. The impact is negligible and entirely theoretical.
A non-exploitable weakness was found in how the client-supplied JWTs are verified. Because an explicit allow-list
of known algorithms is used in the PyJWT library, user-supplied (invalid) algorithms are rejected.
If this was not the case, then the client JWTs could be tampered with, resulting in privilege escalation which
would allow the attacker to perform any operation as any client (impersonation) without leaving a trace of
the real user/client.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-C4CM-R9FH-JGJ9? GHSA-C4CM-R9FH-JGJ9 is a low-severity security vulnerability in commonground-api-common (pip), affecting versions <= 1.12.1. No fixed version is listed yet.
- Which packages are affected by GHSA-C4CM-R9FH-JGJ9?
commonground-api-common(pip) (versions <= 1.12.1)vng-api-common(pip) (versions <= 2.0.5)vng-api-common-utrecht(pip) (versions <= 1.3.2)
- Is there a fix for GHSA-C4CM-R9FH-JGJ9? No fixed version is listed for GHSA-C4CM-R9FH-JGJ9 yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is GHSA-C4CM-R9FH-JGJ9 exploitable, and should I be worried? Whether GHSA-C4CM-R9FH-JGJ9 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-C4CM-R9FH-JGJ9 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.