Every CVE Search/ Get API key

CVE-2025-69207

Khoj has an IDOR in Notion OAuth Flow Enables Index Poisoning

5.4 Medium

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

0.41%Up 0.4 points since Feb 3, 2026
90%50%10%1%

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 MediumCVSS: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 MediumCVSS: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 MediumCVSS: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 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
CVSS 3.1
7.1 HighCVSS: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 MediumCVSS: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 MediumCVSS: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 MediumCVSS: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

Affected packages
PackageAffectedFixed
khoj
PyPI
through 2.0.0b25.dev3 None known
khoj
PyPI
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 less
1.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

History
RecordedChangedSources
first indexedCVE 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

This page doesn't list everything

Left out here: 527 versions. The JSON record has them.

MoveEnter Open