This is a remote code execution vulnerability in Perspective 5.0.0 where the intended security control — clearing __builtins__ — provides virtually no protection against a motivated attacker. The protobuf message handlers TableValidateExprReq and TableMakeViewReq accept client-supplied expressions and evaluate them through eval() with only __builtins__={} as the barrier. This mitigation fails completely because clearing builtins removes only the shorthand names for built-in functions; it does not remove built-in types or break the type hierarchy that Python exposes through type.subclasses(). An attacker with control over the expression string can invoke type.subclasses() to obtain a list of all currently loaded classes in the interpreter, traverse that list to locate subprocess.Popen, and instantiate it with arbitrary shell commands. This technique has been documented since at least 2012 and appears in every standard Python sandbox escape training module — it is not a novel or clever bypass but the canonical failure mode for builtins={} sanitization. The protobuf interface being the attack surface is notable: this is not a forgotten debug endpoint but a structured, presumably intentional API layer. That means the eval capability was an architectural decision, not accidental exposure. Do not attempt to patch this by restricting subclasses or implementing custom containment — those measures are routinely bypassed. The only reliable remediation is removing the eval path entirely from the protobuf handlers. As a defender, you should: confirm whether TableValidateExprReq and TableMakeViewReq are exposed without authentication in your deployment, treat any eval() path in network-facing code as immediate critical risk regardless of apparent sanitization, and audit other protobuf handlers in the same service for similar patterns — if one team believed builtins={} was sufficient, they likely applied similar logic elsewhere. The vulnerability is straightforward: code that should not exist was built, secured with a measure that has never worked, and exposed to the network.
CVE-2026-67195
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedPerspective 5.0.0 contains a remote code execution vulnerability that allows unauthenticated attackers to execute arbitrary operating system commands by submitting crafted expression strings to the PolarsVirtualServer backend, which passes client-supplied input directly to Python's eval() with only __builtins__={} cleared. Attackers can exploit Python object attribute traversal through the interpreter's loaded class list to reach subprocess.Popen via a TableValidateExprReq or TableMakeViewReq protobuf message, achieving arbitrary command execution in the Perspective host process.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisA detailed technical summary for this CVE is being prepared.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor dataThere is no version to upgrade to and no patch to apply. Every affected install stays exposed until the vendor ships a fix — or somebody else builds one.
Free. We build fixes in the order the community asks for them — and we’ll tell you the moment this one lands.
We develop and verify an original fix where the vendor hasn’t, from $1,950. Deployed to your staging first — never straight to production.
Scope it with usSee what else the community needs solved on the solutions-needed board.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-67195 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesThis is a remote code execution vulnerability in Perspective 5.0.0 where the intended security control — clearing `__builtins__` — provides virtually no protection against a motivated attacker. The protobuf message handlers TableValidateExprReq and TableMakeViewReq accept client-supplied expressions and evaluate them through eval() with only `__builtins__={}` as the barrier. This mitigation fails completely because clearing __builtins__ removes only the shorthand names for built-in functions; it does not remove built-in types or break the type hierarchy that Python exposes through type.__subclasses__(). An attacker with control over the expression string can invoke type.__subclasses__() to obtain a list of all currently loaded classes in the interpreter, traverse that list to locate subprocess.Popen, and instantiate it with arbitrary shell commands. This technique has been documented since at least 2012 and appears in every standard Python sandbox escape training module — it is not a novel or clever bypass but the canonical failure mode for __builtins__={} sanitization. The protobuf interface being the attack surface is notable: this is not a forgotten debug endpoint but a structured, presumably intentional API layer. That means the eval capability was an architectural decision, not accidental exposure. Do not attempt to patch this by restricting __subclasses__ or implementing custom containment — those measures are routinely bypassed. The only reliable remediation is removing the eval path entirely from the protobuf handlers. As a defender, you should: confirm whether TableValidateExprReq and TableMakeViewReq are exposed without authentication in your deployment, treat any eval() path in network-facing code as immediate critical risk regardless of apparent sanitization, and audit other protobuf handlers in the same service for similar patterns — if one team believed __builtins__={} was sufficient, they likely applied similar logic elsewhere. The vulnerability is straightforward: code that should not exist was built, secured with a measure that has never worked, and exposed to the network.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-67195 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data