CVE-2025-69207
Khoj has an IDOR in Notion OAuth Flow Enables Index Poisoning
Khoj is a self-hostable artificial intelligence app. Prior to 2.0.0-beta.23, an IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index. This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present. This vulnerability is fixed in 2.0.0-beta.23.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- Required
What an attacker can affect
- Confidentiality
- None
- Integrity
- Low
- Availability
- Low
Exploit likelihood
What each source reports
CVE List Score used
5.4
Khoj has an IDOR in Notion OAuth Flow Enables Index Poisoning
Khoj is a self-hostable artificial intelligence app. Prior to 2.0.0-beta.23, an IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index. This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present. This vulnerability is fixed in 2.0.0-beta.23.
- Record
CVE-2025-69207- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Weakness
- CWE-639
- Updated
- 2026-11-02
EUVDEUVD-2025-206746
5.4
Khoj is a self-hostable artificial intelligence app. Prior to 2.0.0-beta.23, an IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index. This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present. This vulnerability is fixed in 2.0.0-beta.23.
- Record
EUVD-2025-206746- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-6whj-7qmg-86qj
5.4
Khoj has an IDOR in Notion OAuth Flow that Enables Index Poisoning
Summary
An IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index.
This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present.
Details
When users share conversations which contain AI generated images, the file path for the image is constructed using the user's UUID. Knowing this UUID, an attacker is able to intercept the OAuth callback for Notion and replace the state parameter with the other user's UUID and sync notion onto their account.
PoC
The vulnerable line of code exists in src/khoj/routers/notion.py on the callback endpoint.
@notion_router.get("/auth/callback")
async def notion_auth_callback(request: Request, background_tasks: BackgroundTasks):
code = request.query_params.get("code")
state = request.query_params.get("state") # <-- Attacker controlled
if not code or not state:
return Response("Missing code or state", status_code=400)
user: KhojUser = await aget_user_by_uuid(state) # <-- No verification!
await NotionConfig.objects.filter(user=user).adelete() # <-- Deletes victim's config
# ... OAuth token exchange ...
access_token = final_response.get("access_token")
await NotionConfig.objects.acreate(token=access_token, user=user) # <-- Stores attacker's token
To exploit is relatively easy. Once we know the victim's UUID, we simply initiate the Notion sync process on our own account and intercept the callback, replacing the state parameter with the victim's UUID.
Impact
Deletes user's existing Notion sync and replaces it with attacker-controlled Notion. Could allow for index poisoning. I'm not entirely sure what Khoj does with synced files but if it's being passed as context to an LLM then I can imagine there's potential here.
- Record
GHSA-6whj-7qmg-86qj- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Weakness
- CWE-639, CWE-862
- Updated
- 2026-11-02
NVD
5.4
Khoj is a self-hostable artificial intelligence app. Prior to 2.0.0-beta.23, an IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index. This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present. This vulnerability is fixed in 2.0.0-beta.23.
- Record
CVE-2025-69207- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N - Weakness
- CWE-639
- Updated
- 2026-11-02
OSV
5.4
Khoj has an IDOR in Notion OAuth Flow Enables Index Poisoning
Khoj is a self-hostable artificial intelligence app. Prior to 2.0.0-beta.23, an IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index. This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present. This vulnerability is fixed in 2.0.0-beta.23.
- Record
CVE-2025-69207- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Weakness
- CWE-639
- Updated
- 2026-11-02
OSVGHSA-6whj-7qmg-86qj
5.4
Khoj has an IDOR in Notion OAuth Flow that Enables Index Poisoning
Summary
An IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index.
This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present.
Details
When users share conversations which contain AI generated images, the file path for the image is constructed using the user's UUID. Knowing this UUID, an attacker is able to intercept the OAuth callback for Notion and replace the state parameter with the other user's UUID and sync notion onto their account.
PoC
The vulnerable line of code exists in src/khoj/routers/notion.py on the callback endpoint.
@notion_router.get("/auth/callback")
async def notion_auth_callback(request: Request, background_tasks: BackgroundTasks):
code = request.query_params.get("code")
state = request.query_params.get("state") # <-- Attacker controlled
if not code or not state:
return Response("Missing code or state", status_code=400)
user: KhojUser = await aget_user_by_uuid(state) # <-- No verification!
await NotionConfig.objects.filter(user=user).adelete() # <-- Deletes victim's config
# ... OAuth token exchange ...
access_token = final_response.get("access_token")
await NotionConfig.objects.acreate(token=access_token, user=user) # <-- Stores attacker's token
To exploit is relatively easy. Once we know the victim's UUID, we simply initiate the Notion sync process on our own account and intercept the callback, replacing the state parameter with the victim's UUID.
Impact
Deletes user's existing Notion sync and replaces it with attacker-controlled Notion. Could allow for index poisoning. I'm not entirely sure what Khoj does with synced files but if it's being passed as context to an LLM then I can imagine there's potential here.
- Record
GHSA-6whj-7qmg-86qj- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Weakness
- CWE-639, CWE-862
- Updated
- 2026-11-02
OSVPYSEC-2026-1491
5.4
Khoj has an IDOR in Notion OAuth Flow that Enables Index Poisoning
Summary
An IDOR in the Notion OAuth callback allows an attacker to hijack any user's Notion integration by manipulating the state parameter. The callback endpoint accepts any user UUID without verifying the OAuth flow was initiated by that user, allowing attackers to replace victims' Notion configurations with their own, resulting in data poisoning and unauthorized access to the victim's Khoj search index.
This attack requires knowing the user's UUID which can be leaked through shared conversations where an AI generated image is present.
Details
When users share conversations which contain AI generated images, the file path for the image is constructed using the user's UUID. Knowing this UUID, an attacker is able to intercept the OAuth callback for Notion and replace the state parameter with the other user's UUID and sync notion onto their account.
PoC
The vulnerable line of code exists in src/khoj/routers/notion.py on the callback endpoint.
@notion_router.get("/auth/callback")
async def notion_auth_callback(request: Request, background_tasks: BackgroundTasks):
code = request.query_params.get("code")
state = request.query_params.get("state") # <-- Attacker controlled
if not code or not state:
return Response("Missing code or state", status_code=400)
user: KhojUser = await aget_user_by_uuid(state) # <-- No verification!
await NotionConfig.objects.filter(user=user).adelete() # <-- Deletes victim's config
# ... OAuth token exchange ...
access_token = final_response.get("access_token")
await NotionConfig.objects.acreate(token=access_token, user=user) # <-- Stores attacker's token
To exploit is relatively easy. Once we know the victim's UUID, we simply initiate the Notion sync process on our own account and intercept the callback, replacing the state parameter with the victim's UUID.
Impact
Deletes user's existing Notion sync and replaces it with attacker-controlled Notion. Could allow for index poisoning. I'm not entirely sure what Khoj does with synced files but if it's being passed as context to an LLM then I can imagine there's potential here.
- Record
PYSEC-2026-1491- CVSS 3.1
- 5.4 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
khojPyPI |
through 2.0.0b25.dev3 | None known |
khojPyPI |
through 2.0.0b25.dev3, plus listed versions 1.01.16.1.dev151.16.1.dev161.16.1.dev251.16.1.dev26 Show 45 moreShow less1.16.1.dev471.17.01.17.1.dev2161.17.1.dev2171.17.1.dev2181.17.1.dev2191.17.1.dev2201.17.1.dev2211.17.1.dev2221.17.1.dev2231.17.1.dev2291.17.1.dev2331.20.01.20.1.dev11.20.1.dev111.20.1.dev21.20.1.dev31.20.1.dev41.20.1.dev51.20.1.dev61.20.21.20.2.dev11.20.2.dev51.20.2.dev61.20.2.dev81.20.31.20.3.dev11.20.3.dev101.20.3.dev111.20.3.dev131.20.3.dev141.20.3.dev151.20.3.dev21.20.41.20.4.dev11.20.4.dev131.20.4.dev21.20.4.dev51.20.4.dev61.20.4.dev81.20.4.dev91.20.5.dev11.20.5.dev101.20.5.dev151.20.5.dev16 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2025-69207 is a medium vulnerability (CVSS 5.4) in Khoj, published February 2, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.41%, the 36th percentile. No source names a fixed version.
References
github.com/khoj-ai/khoj/security/advisories/GHSA-6whj-7qmg-86qj
github.com/khoj-ai/khoj/commit/1b7ccd141d47f365edeccc57d7316cb0913d748b
github.com/khoj-ai/khoj/releases/tag/2.0.0-beta.23
nvd.nist.gov/vuln/detail/CVE-2025-69207
github.com/advisories/GHSA-6whj-7qmg-86qj
github.com/CVEProject/cvelistV5/tree/main/cves/2025/69xxx/CVE-2025-69207.json
github.com/khoj-ai/khoj
pypi.org/project/khoj
Left out here: 527 versions. The JSON record has them.