Skip to content

Python: CVE-2026-26030 / GHSA-xjw9-4gw8-4rqx: question on the PR:L component of the CVSS vector #14412

Description

Context

I'm trying to understand the reasoning behind the PR:L component in the CVSS vector for CVE-2026-26030 / GHSA-xjw9-4gw8-4rqx (InMemoryVectorStore filter RCE, fixed in python-1.39.4):

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

This isn't a request to change the score — I'm asking a downstream question about what CISA-ADP's SSVC Automatable assessment (currently no, see cisagov/vulnrichment#336) was likely built on, since CISA's own SSVC guide treats PR:L-style authentication requirements as a typical barrier to automation.

Question

What kind of privilege was PR:L meant to represent — an authenticated/permissioned call to the hosting application (something an anonymous internet user couldn't obtain), or just whatever minimal session/identity the hosting application happens to require before it will call the vector store at all, even if that's a free, unverified self-service signup?

I ask because for a common deployment pattern — a public-facing RAG chatbot where "logging in" just means starting a session with no identity verification — the practical barrier to reaching this code path may be much lower than PR:L usually implies. Knowing which assumption was used when scoring would help me understand (and pass along accurately) what the CVSS is actually saying about exploitability here.

Not urgent — mainly trying to reconcile the CVSS with the SSVC Automatable value assigned downstream. Thanks.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    .NETIssue or Pull requests regarding .NET codepythonPull requests for the Python Semantic Kerneltriage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions