GHSA-53wg-r69p-v3r7 — graphql-modules
Fix: graphql-hive/graphql-modules#2521GHSA-53wg-r69p-v3r7 is a CWE-362 vulnerability in graphql-modules. A fix is available for graphql-modules — see the affected versions and patch details below.
GraphQL Modules has a Race Condition issue
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-53wg-r69p-v3r7.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
graphql-modulesnpmDescription
Summary
Originally reported as an issue #2613 but should be elevated to a security issue as the ExecutionContext is often used to pass authentication tokens from incoming requests to services loading data from backend APIs.
Details
When 2 or more parallel requests are made which trigger the same service, the context of the requests is mixed up in the service when the context is injected via @ExecutionContext()
PoC
In a new project/folder, create and install the following package.json:
{
"name": "GHSA-53wg-r69p-v3r7",
"scripts": {
"test": "jest"
},
"dependencies": {
"graphql-modules": "2.4.0"
},
"devDependencies": {
"@babel/plugin-proposal-class-properties": "^7.18.6",
"@babel/plugin-proposal-decorators": "^7.28.6",
"babel-plugin-parameter-decorator": "^1.0.16",
"jest": "^29.7.0",
"reflect-metadata": "^0.2.2"
}
}
with:
npm i
configure babel.config.json using:
{
"plugins": [
["@babel/plugin-proposal-decorators", { "legacy": true }],
"babel-plugin-parameter-decorator",
"@babel/plugin-proposal-class-properties"
]
}
then write the following test GHSA-53wg-r69p-v3r7.spec.ts:
require("reflect-metadata");
const {
createApplication,
createModule,
Injectable,
Scope,
ExecutionContext,
gql,
testkit,
} = require("graphql-modules");
test("accessing a singleton provider context during another asynchronous execution", async () => {
@Injectable({ scope: Scope.Singleton })
class IdentifierProvider {
@ExecutionContext()
context;
getId() {
return this.context.identifier;
}
}
const { promise: gettingBefore, resolve: gotBefore } = createDeferred();
const { promise: waitForGettingAfter, resolve: getAfter } = createDeferred();
const mod = createModule({
id: "mod",
providers: [IdentifierProvider],
typeDefs: gql`
type Query {
getAsyncIdentifiers: Identifiers!
}
type Identifiers {
before: String!
after: String!
}
`,
resolvers: {
Query: {
async getAsyncIdentifiers(_0, _1, context) {
const before = context.injector.get(IdentifierProvider).getId();
gotBefore();
await waitForGettingAfter;
const after = context.injector.get(IdentifierProvider).getId();
return { before, after };
},
},
},
});
const app = createApplication({
modules: [mod],
});
const document = gql`
{
getAsyncIdentifiers {
before
after
}
}
`;
const firstResult$ = testkit.execute(app, {
contextValue: {
identifier: "first",
},
document,
});
await gettingBefore;
const secondResult$ = testkit.execute(app, {
contextValue: {
identifier: "second",
},
document,
});
getAfter();
await expect(firstResult$).resolves.toEqual({
data: {
getAsyncIdentifiers: {
before: "first",
after: "first",
},
},
});
await expect(secondResult$).resolves.toEqual({
data: {
getAsyncIdentifiers: {
before: "second",
after: "second",
},
},
});
});
function createDeferred() {
let resolve, reject;
const promise = new Promise((res, rej) => {
resolve = res;
reject = rej;
});
return {
promise,
resolve,
reject,
};
}
and execute using:
npm test
Your project tree should look like this:
GHSA-53wg-r69p-v3r7
package.json
package-lock.json
babel.config.json
GHSA-53wg-r69p-v3r7.spec.js
Expected vs. Actual Outcome
- Expected - 1
+ Received + 1
Object {
"data": Object {
"getAsyncIdentifiers": Object {
- "after": "first",
+ "after": "second",
"before": "first",
},
},
}
Impact
Any application that uses services that inject the context using @ExecutionContext() from a singleton provider are at risk. The more traffic an application has, the higher the chance for parallel requests, the higher the risk.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | graphql-modules | ≥ 2.2.1&&< 2.4.1 | 2.4.1npm install graphql-modules@2.4.1 |
| 📦npm | graphql-modules | ≥ 3.0.0&&< 3.1.1 | 3.1.1npm install graphql-modules@3.1.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for graphql-modules, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update graphql-modules to 2.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-53wg-r69p-v3r7 is resolved across your whole dependency graph.
Workarounds
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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-53wg-r69p-v3r7 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-53wg-r69p-v3r7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-53wg-r69p-v3r7 in your dependencies?
O3 Security finds GHSA-53wg-r69p-v3r7 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.