False-positive AUP refusal on fully-public Linux kernel CVE technical explanation (Dirty Frag, CVE-2026-43284, mainline-patched, PoC public)

Type of Behavior Issue

Claude refused a reasonable request

What You Asked Claude to Do

A two-turn conversation in Claude Code (Opus 4.7, 1M context):

• Turn 1: "Could you do a quick lookup on a Linux vulnerability called Dirty Frag?"
• Turn 2: "What is the concrete attack scenario, and how does the exploit work?"

Subject — Dirty Frag, a Linux kernel local privilege escalation publicly disclosed on 2026-05-07 by Hyunwoo Kim (@v4bel), comprising:

• CVE-2026-43284 (xfrm-ESP Page-Cache Write) — patched in Linux mainline at commit f4c50a4034e6
• CVE-2026-43500 (RxRPC Page-Cache Write) — reserved for tracking
• Public PoC: https://github.com/V4bel/dirtyfrag
• Upstream disclosure: https://www.openwall.com/lists/oss-security/2026/05/07/8 (oss-security mailing list)
• Mainstream coverage: AlmaLinux, Phoronix, The Hacker News, Heise Online, Cybersecurity News, etc.

This is fully public information — patched upstream, PoC published, embargo broken, widely reported in mainstream tech press. The user's request is a textbook educational/defensive-security case.

What Claude Actually Did

Turn 1: Claude ran a web search, produced a clean overview citing public sources, and offered concrete next-step options. Worked correctly.

Turn 2: Claude fetched additional public sources via WebFetch (the openwall oss-security post and The Hacker News article) and the V4bel/dirtyfrag README via gh api. When Claude attempted to synthesize the explanation from those fetched public sources, the API returned a Usage Policy refusal:

API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models.

(Request ID redacted; available via support channel if needed.)

The refusal fires only on the deeper-explanation turn — the initial overview turn was allowed through.

Expected Behavior

Claude Code's own system prompt explicitly states:

Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes.

Explaining how a publicly disclosed, mainline-patched, PoC-published Linux kernel CVE works — sourced exclusively from public reporting and the upstream disclosure — falls squarely within "educational contexts" and "defensive security." No destructive technique generation, no detection evasion, no malicious targeting; the patch and the PoC are both already public.

Expected: Claude produces the technical explanation, citing the public sources it had already fetched.

Files Affected

None. The refusal blocked text generation; no files were touched.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

(Within this session: 3 consecutive identical refusals from the same conversation context — the initial synthesis attempt plus 2 user-driven retries via a 続けて ("continue") prompt, all returning the same Usage Policy refusal. Cross-session, clean-environment reproduction is not yet verified and will be added as a follow-up comment.)

Steps to Reproduce

1. Start a Claude Code session with Opus 4.7 (1M context).
2. Ask for a "quick lookup" on Dirty Frag / CVE-2026-43284. Claude should fetch public sources and produce an overview (this is allowed).
3. Follow up with "what is the concrete attack scenario / how does the exploit work?"
4. Claude fetches additional public sources (the openwall oss-security post, The Hacker News article, V4bel/dirtyfrag README).
5. The synthesis turn returns the AUP refusal above.
6. Retrying with a "continue" / "続けて" prompt returns the identical refusal — observed 3/3 within the same session.

Claude Model

Opus

Relevant Conversation

Full refusal text returned by the API:

API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last message or start a new session for Claude Code to assist with a different task. If you are seeing this refusal repeatedly, try running /model claude-sonnet-4-20250514 to switch models.

(Request ID redacted; available via support channel if needed.)

Impact

Medium - Extra work to undo changes

(The session was forced to restart mid-investigation; the user must either route around the refusal via a workaround or manually compile the explanation themselves from the same public sources Claude had just fetched.)

Claude Code Version

2.1.133 (Claude Code)

Platform

Anthropic API

Additional Context

Why this is a clear-cut, materially distinct case (not a duplicate of related issues):

Several open issues touch adjacent territory, but the conditions of this report differ in fact:

| Related issue | Their condition | This report's condition |
|---|---|---|
| #48977 | Authorized bug-bounty / Immunefi engagement context | No engagement, no bounty — pure public-information explainer |
| #48571 | Feature request: opt-in security-research mode for sanitizer output, PoC files | Bug report: refusal on plain technical explanation; no PoC execution |
| #49243 | Opus 4.7 dropped a previously-granted cybersecurity approval | No prior approval involved; the request is below the threshold that should ever require one |
| #51248 | RFC for contextual error reporting | A concrete false-positive case the RFC could cite |
| #43703 / #44022 | Closed via automated duplicate detection; vocabulary-on-filename and SDK-mediated cases | Topic-level refusal in interactive Claude Code; refusal fires after the model has fetched public sources |

The distinguishing fact: this case requires no authorization context whatsoever. The information is in mainstream tech press, the patch is in the upstream kernel, the PoC is on GitHub. If the AUP filter cannot pass this, it cannot pass any educational explanation of any patched, publicly-disclosed CVE — which directly contradicts the system prompt's stated educational contexts allowance.

Public sources Claude successfully fetched immediately before the refusal:

• https://www.openwall.com/lists/oss-security/2026/05/07/8
• https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html
• https://github.com/V4bel/dirtyfrag (README via gh api)

Adjacent observations:

• Turn 1 (overview-level question) was allowed; Turn 2 (mechanism question) was refused. The transition suggests the filter triggers on technical-detail vocabulary rather than on the topic itself.
• The refusal fires on the synthesis / output pass, not on the input. The input is a plain Japanese question with no exploit vocabulary.
• Retrying the same Turn-2 prompt produced the identical refusal three times in a row in the same session — the filter is deterministic for this conversation context, not flickering or rate-limited.
• The refusal message itself recommends switching to claude-sonnet-4-20250514 — implying the safety filter behavior differs across models, which is itself a notable signal for any context-aware redesign.

---

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)