Skip to content

Science1 publisher3 min readPublished

Stripping refusals from Gemma tilted its bug verdicts toward yes

A researcher ran the same FreeBSD scan through base and abliterated open-weight builds and found the uncensored ones graduating three to four times as many findings, while the most aggressive one never surfaced the actual CVE.

The Scientist · Science desk

Illustration accompanying Stripping refusals from Gemma tilted its bug verdicts toward yes

What happened

  • A researcher held a scan-and-triage pipeline constant over the same FreeBSD source and swapped only the model, checking which local open-weight builds could find a known kernel CVE.
  • The abliterated builds, same family and parameter count with refusal weights edited out, graduated three to four times as many findings to VALID, including a false positive the base model rejected.
  • On auth_unix.c, the build labelled ultra-uncensored Gemma 4 26b Heretic raised six candidate findings and confirmed all six, on a file the base build walked away from without reporting anything.

Compiled by The ScientistSomething wrong?How this is made

Why it matters

  • cost Every finding a base model graduates arrives as three or four in the uncensored run, so the reviewer absorbs two to three extra reads per genuine item, and that reading is the expensive part of bug hunting.
  • constraint A pipeline that leans on model triage to hold precision loses that control when the triage step confirms everything its own scan raised, which pushes the filtering back onto people.
  • decision Anyone picking uncensored weights to avoid refusals is now choosing between refusal-free scanning and calibrated verdicts, rather than getting the first for free.
  • contradiction The three-to-four-times figure is reported across the abliterated builds while the total miss on the real CVE is attributed to the single most aggressive one, so the severity of the trade depends on which build you actually run.

What the write-up describes is a reasoning trace in which the model locates the reason to reject a finding and then returns a positive verdict anyway [5]. Candidate C5 shows the shape. It claims a heap overflow in `marshal_new_auth`, arguing that `au->au_marshed` is the buffer handed to `xdrmem_create` and that marshaled data exceeding `MAX_AUTH_BYTES` will overrun it, at a stated confidence of 4 [15]. Read the function and `MAX_AUTH_BYTES` is the size of that buffer and the bound passed to the stream writing into it, set on the first of the three lines the candidate cites, with a comment above saying so [16]. The model narrates the bound, then narrates the overflow of the thing it has just bounded [17].

Three to four times as many graduated findings means that for every finding a base model puts in your report, the uncensored build hands you two or three more to read [22]. On `auth_unix.c` the ratio is worse than that: six candidates raised and six confirmed, nothing filtered out by the model's own triage step [20], on a file where the base build reported nothing at all [11].

The design is tight in the way that matters. Only the model changed: same family, same parameter count, the same scan prompt over the same FreeBSD source [6][2]. That rules out prompt drift and parameter count as explanations, but it does not isolate the mechanism. Abliteration edits weights to strip refusals [2], and the author's stated worry going in was that the edit takes more than refusal with it [18]; what the run shows is a yes-bias travelling with the edit. It does not show that a refusal and a negative verdict are the same object inside the model. One known CVE, one codebase, one candidate carried through triage across three models [13] shows a direction only; the effect size itself won't transfer to your own corpus.

The scan prompt explicitly told the model to be picky and throw out the theoretical stuff [7]. The base builds obliged, each stopping at the one real bug [9]. The figure that should govern the decision is the miss rather than the multiplier, because the most aggressive uncensored build never surfaced that bug anywhere in the directory [4], so volume rose while recall on the one question with a known answer went to zero [21]. The zero-recall result belongs to that single build, while the three-to-four-times figure is what the author reports across the abliterated set [3][4].

For anyone reaching for local uncensored weights to get past refusals in vulnerability research [18], the trade now carries a visible cost further down the pipeline. The scanner gets louder, and the judge agrees with it.

What to watch

  • Per-model counts across a second codebase and a second known CVE would show whether the three-to-four-times gap holds or was specific to these Gemma builds on FreeBSD.
  • A run where the abliterated model triages the base model's candidates would separate a biased scanner from a biased judge.
  • Whether lighter refusal-removal methods than the Heretic build produce the same tilt in verdicts, or a smaller one.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories