DEV Community: Amartya Jha

Dissecting FOIS: The Log4j2 Filter That Only Does Half Its Job

Amartya Jha — Tue, 01 Sep 2026 06:56:17 +0000

__Log4j2's FilteredObjectInputStream checks which classes can be rebuilt, but not how large or deep the data can be. Here's how that gap enables an RCE and two gadget-free crashes on a serialized log receiver.

TL;DR

Log4j2's FilteredObjectInputStream (FOIS) checks the class names in a serialized stream and nothing else. It never limits object size or depth.
That one gap gives three problems on a single network log receiver: an unauthenticated RCE, a crash that pins a CPU core, and a 44-byte out-of-memory crash. Two of them need no exploit gadget.
The RCE (Log4j2 #4255) is prior work. CodeAnt's contribution is dissecting the two crashes, the contrast with logback, and the lab numbers.
Exposure is narrow. You need a serialized log receiver on the network, which is not a Log4j default. High severity, low prevalence.
Fix: send logs as text, or add the size and depth caps logback already ships.

At a Glance

A security filter is meant to do one job completely. FOIS does about half of one. It reads the name of every class arriving over the network and rejects anything not on an approved list.

That is a real check, but it is the only check. FOIS never asks how large an object is or how deeply nested, and it never turns on the size and depth limits Java already ships. Those two missing checks turn one log receiver into three problems.

The RCE below (Log4j2 #4255) is not our discovery; it is prior work, credited in full at the end.

What our team adds is the breakdown of the filter itself: the two crashes hiding in the limits FOIS forgot to set, the comparison with the library that got it right, and numbers from a real lab.

Read the full CodeAnt security research →

Lab: Log4j 2.26.1 on JDK 17. Run it yourself with one Docker command.

What FOIS Was Built To Do

Log4j can ship log events between machines as Java objects, and the receiver rebuilds them from raw bytes. Rebuilding attacker-controlled bytes is the flaw behind a decade of Java RCE, so Apache wrapped that step in FOIS in Log4j 2.8.2 (the fix for CVE-2017-5645). FOIS keeps the class names it trusts and throws out the rest.

Two details of that trusted list matter. It allows a class called java.rmi.MarshalledObject, and it trusts whole Java packages by prefix, so everything under java.util and java.lang is waved through. Each one becomes a way in.

The One Mistake

FOIS checks which class is being rebuilt. It never checks how big or how deep. Java can cap array size, nesting depth, and reference count; FOIS turns none of that on. Everything below follows from that.

The Three Impacts

RCE — a java.rmi.MarshalledObject-wrapped gadget hits the FilteredObjectInputStream receiver; the receiver logs msg=null while whoami returns root, unauthenticated code execution as root.

DoS — the same receiver, no gadget: a 5.7 KB nested HashSet pins readObject at 100% CPU permanently, and a 44-byte Object array triggers OutOfMemoryError: Requested array size exceeds VM limit.

One: remote code execution, smuggled inside an allowed class. MarshalledObject is trusted, but it is a container: it carries a second batch of bytes inside itself, and when Log4j opens it, those inner bytes are rebuilt on a fresh stream that FOIS is not watching.

The outer check passes; the real payload rides in behind it. Log4j opens the container on its own during reconstruction, so if the server has a usable gadget library on its classpath, this is unauthenticated RCE.

In the lab against real Log4j 2.26.1 on JDK 17, a wrapped payload ran whoami and returned root, the server stayed up and logged a blank message, and the same payload sent without the container was correctly rejected. (On a modern JDK fewer gadgets survive, but the ones that run commands still work where the right library is present, so the requirement is just a usable gadget on the classpath.)

Two: a CPU bomb the size of a text message. HashSet is allowed, and rebuilding a set recomputes the hash of everything inside it.

A 2015 trick called SerialDOS (Wouter Coekaerts) builds a small nested structure where each layer is shared and referenced twice, so a shape a few dozen levels deep is reachable by an exponential number of paths, and the runtime walks every one. With no depth limit, the receiver runs it to completion:

A few kilobytes freezes the machine, one worker per packet, and it is silent: while the receiver spins there is no log line. The only sign is a thread stuck at 100% CPU.

Three: a 44-byte packet that crashes the process. A serialized array states its length before any data, and the runtime reserves that space immediately. With no size limit, that number can be anything.

A 44-byte packet can claim an array of billions of entries, and the process dies with an out-of-memory error before it even tries to allocate. No gadget, no library, just a lie about size.

The full research walks through the FOIS implementation, reproduces all three impact paths, and includes the lab setup and measurements.

Read the complete analysis →

How logback Solved the Same Problem

logback, Spring Boot's default logger, had the identical socket receiver, and its guard shows what the finished job looks like. HardenedObjectInputStream does everything FOIS does, then the part FOIS skipped: an exact-name allowlist instead of trusting whole packages, a maximum array size and nesting depth (which kills both crashes), and a closed proxy path.

It is immune to all three. The difference between the two libraries is essentially one extra line of filter, the one that turns on the size and depth caps, which FOIS never wrote.

How Exposed Is This, Really?

Less than three impacts suggests, and this is the honest part. Every one needs a serialized log receiver exposed on the network, which is not how Log4j runs by default; Apache removed the built-in socket server years ago. When one researcher tested 53 product builds in default configuration, none were exploitable.

Call it high severity, low prevalence: trivial to hit where a receiver exists, uncommon to have one. Where they do appear, it tends to be logback's own socket receiver, an older Elastic Logstash log4j input, or legacy Log4j 1.x, which has no filter at all.

How To Fix It

If you cannot remove a serialized receiver right away, one runtime setting closes the gaps. It denies the gadget package and adds the size and depth caps at once. The catch: only one such filter applies per process and a later setting silently replaces an earlier one, so every rule lives in a single string.

-Djdk.serialFilter='!org.apache.commons.collections.**;maxarray=10000;maxdepth=16'

That is a stopgap. The durable fix is to stop sending Java objects across a trust boundary: carry log events as JSON or plain text, or remove the serialized receiver. Log4j 3.x already dropped this pattern; the 2.x line still in production keeps it.

Are You Affected?

Only if you run a serialized log receiver reachable on the network, which is a deliberate setup, not a default. Look for a process listening on a log-ingest port (historically 4560) that rebuilds log events off the socket.

If you find one, treat it as high severity, apply the filter above, then move that transport to text or retire it. On Log4j 3.x the pattern is already gone.

Original research: U-Sec / Wujie Security, first credited with the MarshalledObject allowlist bypass behind #4255. The original report was later deleted.
Independent PoCs: joanbono's log4j2-4255-exploit and dinosn's log4j-4255.
CPU-crash technique: Wouter Coekaerts, "SerialDOS," 2015.
Prior writeup: Jeff McJunkin's post, whose 53-product test and detection guidance inform the exposure and fix sections.

Credit: Prior Work

The RCE (issue #4255), the property that any gadget works once the inner stream is unchecked, and the gadgets themselves are prior work. Our contribution is the breakdown of the filter around that RCE, the two crashes from its missing limits, the logback comparison, and the lab numbers.

The Takeaway

A class-name allowlist is not a deserialization boundary. Restricting which objects can be rebuilt may reduce the risk of code execution, but without limits on payload size, object depth, or resource consumption, the same endpoint can remain vulnerable to denial of service.

The bigger lesson is simple: a security control is only as strong as the attack surface it actually closes. An endpoint can look hardened against one exploit path while still being wide open to another.

If your application relies on deserialization, APIs, or other security-sensitive boundaries, automated checks alone may not expose these gaps. That is where adversarial testing matters.

Want to know what your application exposes before an attacker does?

CodeAnt AI helps teams identify security weaknesses across their codebase and infrastructure. For deeper coverage, CodeAnt's pentesting services put those controls to the test from an attacker's perspective, helping uncover exploitable paths that static analysis and automated scanners can miss.

If you want to see the kind of security research behind that approach, read the full Log4j2 FOIS analysis.

Find the weakness before someone else does.

References

Apache Log4j2 issue #4255
logback HardenedObjectInputStream
ysoserial · log4j2-4255-lab · Jeff McJunkin
CVEs: CVE-2017-5645, CVE-2017-5929, CVE-2019-17571, CVE-2023-6378

This breakdown is part of an ongoing effort by CodeAnt AI Security Research to analyse the trust boundaries in widely deployed infrastructure. The lab ran in isolated local Docker containers with synthetic payloads. The underlying issue and the gadgets are prior work, credited above.

Have a receiver like this, or want a deserialization boundary reviewed? Reach us at securityresearch@codeant.ai

How a GitHub Triage Role Hijacked an Already-Authorized Claude Code Action Run

Amartya Jha — Mon, 31 Aug 2026 09:14:02 +0000

A GitHub collaborator with only the triage role could shift Claude Code Action's authorized trigger boundary and inject post-authorization input into a repository-writing run.

HackerOne #3918594 · Claude Code Action v1.0.185, commit 9db594c7a0e82298c121c18b7f08aa1579ce7341 · CVSS 4.0 score 7.5, High

Authorizing an automated job is really two promises: who gets to start it, and which data it's allowed to see once running. Most security reviews focus on the first and barely glance at the second, which is exactly where CodeAnt AI Security Research went looking in Claude Code Action, the GitHub bot that lets Claude respond to issues and pull requests and push changes back to a repository.

What we found: a collaborator holding nothing more than GitHub's triage role, no write access, no ability to launch Claude directly, could wait for a maintainer to authorize a run and quietly shift that run's own idea of when it had been authorized, so the already-privileged job treated data the collaborator posted afterward as if it had always been there.

This is not ordinary prompt injection. The data in question was created after the cutoff meant to exclude it, and it only got in because that cutoff itself was silently reassigned to a different person's action.

What Claude Code Action is supposed to guarantee

Two controls sit between a GitHub event and a repository-writing Claude run.

The first is a write-permission gate: before Claude gets any repository-writing tools, the Action checks whether the actor behind the triggering webhook actually has write access to the repo.

The second is a temporal cutoff: comments posted or edited after the trigger moment are filtered out of the context Claude sees, so nobody can sneak extra instructions in after a maintainer has already greenlit the run.

Both controls sound airtight individually. We went looking for whether the actor the first control checks and the timestamp the second control uses actually describe the same underlying event. They didn't, at least not for one common trigger type.

Reconstructing a timestamp from the wrong source

For most trigger events, Claude Code Action reads its timestamp from the webhook payload that fired. issues.labeled events work differently: the Action instead queries GitHub's API for the issue's full label history, filters to every event where a matching label was applied, and picks whichever happened most recently.

The resolver, in essence, does this:

const matches = events.filter(
  event => event.event === "labeled" && event.label?.name === labelName
);
const latest = matches.sort(byCreatedAtDescending)[0];
return latest?.created_at;

GitHub's label-event data includes both an actor and a unique event identifier. Neither gets used here. The resolver treats "an event of this type, with this label name, that happened most recently" as if that were enough to identify one specific, authorized event. It isn't.

Two decisions, checking two different things

Split this into the two questions the Action is actually answering.

The first: is this actor allowed to start a write-capable run? Answered by checking context.actor on the original webhook. A maintainer passes; a triage-level collaborator does not.

The second: which repository context belongs to that now-authorized run? Answered, for label triggers, by a live query that ignores actor entirely and just grabs the newest matching event.

permission identity: the original webhook's actor and event
content identity:    whichever live event matches type and label most recently

Those two answers are supposed to describe the same moment. Once they don't, anyone who fails the first question can still shape the outcome of the second, as long as they have enough GitHub permissions to produce a matching event of their own.

Watching the boundary actually move

We built a deterministic timeline to prove this out:

09:59  A maintainer-authored task already exists on the issue
10:01  Maintainer applies the "claude" label
10:02  Triage-level collaborator comments RELEASE_APPROVAL=attacker-controlled
10:03  Same collaborator removes the "claude" label, then reapplies it

At 10:01, when the run is supposed to be authorized, the 10:02 comment doesn't exist yet, so it has to stay out of scope no matter what.

Run the resolver with only the original 10:01 event visible, and it correctly returns 10:01, comment excluded. Add the 10:03 relabel event back in, and the resolver instead returns 10:03. The exact same comment, unchanged, now reads as pre-trigger content and lands in the prompt.

None of this required forging a webhook or impersonating the maintainer. The collaborator used only the ordinary label-management permissions GitHub already grants that role. The authorized job did the substitution itself, by trusting a live, mutable history over the event it was actually triggered by.

What was and wasn't the trusted boundary

To be clear: issue comments were never treated as trusted input, they're expected to be arbitrary and untrusted. Triage collaborators managing labels isn't a flaw either, GitHub deliberately gives that role exactly that capability.

The actual protected boundary is narrower: the snapshot of context that existed at the moment a maintainer's authorization fired. Claude Code Action explicitly filters out anything added after that snapshot so a privileged run's inputs can't shift after the fact.

That distinction, control over post-authorization input rather than simple access to untrusted content, is what separates this from a garden-variety prompt injection report.

Following the mutation all the way to a commit

We split verification into two independent layers so neither claim depended on the other.

The first layer isolated the resolver and prompt-building logic itself: resolveTriggerTimestamp(), fetchGitHubData(), the permission check, and prompt generation, fed scripted responses standing in for a maintainer and a triage-level actor. It confirmed the maintainer's webhook passes the gate cleanly, the triage actor's own webhook fails it every time, and only a later same-label event from the triage actor moves the cutoff.

The second layer went further, into the Action's bundled runtime and its real tag-mode tool access: edit, commit, push, loopback-only, against a local bare repository. The issue held an ordinary maintainer task: take the latest RELEASE_APPROVAL value, write it to a file, commit and push it. The attacker's comment held nothing but a plain value, no jailbreak language. Wherever the rebinding took effect, Claude wrote, committed, and pushed that value; wherever it didn't, the value was simply absent.

Isolating exactly what changed

We designed five controls so each one changed a single security-relevant variable at a time:

Scenario	Permission check	Cutoff selected	Attacker's value	Repository sink
Triage actor triggers directly	Rejected	Never reached	Never reached	No write occurs
Only the maintainer's original event exists	Allowed	10:01	Excluded	No attacker-chosen file
A later event with a different label exists	Allowed	10:01	Excluded	No attacker-chosen file
A later same-label event from the triage actor exists	Allowed, under the maintainer's webhook	10:03	Included	File committed and pushed
Same later event, but actor binding is enforced	Allowed, under the maintainer's webhook	10:01	Excluded	No attacker-chosen file

Every case reproduced across three clean runs each. Notably, the sink-level proof recorded zero permission denials the entire time, because as far as the Action's own logic was concerned, it was still faithfully executing the maintainer's original, authorized job.

What a repository actually loses

Any repository using issues.labeled with a Claude trigger label, combined with a write-capable workflow token, was exposed to having its authorized job's inputs quietly mutated by a collaborator well below write access.

Depending on the maintainer-authored task, admitted data could shape generated source or config, release metadata, the content of Claude's commits, which branches got pushed, and anything downstream that trusted those commits without a second look.

We rated this High rather than Critical: exploitation needs a label-triggered workflow, a collaborator with triage permissions, a timing window before the authorized job finishes its live lookup, and a maintainer task where the admitted data meaningfully changes the output.

Anthropic's assigned score reflects that conditionality:

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

The actual root cause

Underneath the GitHub-specific details, this is a case of mutable semantic attributes standing in for a real event identity.

what should have been bound: the webhook's own, immutable event
what actually got bound:     the newest live event sharing type and label name

event === "labeled" and label.name === "claude" describe a whole class of events, not one specific event. Picking the newest member of that class makes the boundary sensitive to anything that happens after the original authorization, as long as it matches type and label.

The permission check was correct the moment it ran. The comment filter was correct for whatever timestamp it was handed. The failure lived entirely in the handoff between those two steps, where the timestamp's actual origin got lost.

How we'd fix it

The durable solution carries one authenticated event identity, unbroken, from authorization through context collection through execution.

Where GitHub exposes a trusted, immutable delivery identifier, use that instead of reconstructing anything from live history.

Where a live lookup is unavoidable, require the selected event's actor to match the original webhook's actor, anchor candidates to a job-receipt timestamp so nothing afterward can drag the cutoff forward, and fail closed on ambiguity.

Preserve the original webhook payload for trigger-time state, and add regression coverage for a different actor relabeling the issue mid-run.

What this means for agentic CI more broadly

Authorizing a job isn't only a decision about who may start it. It's also, implicitly, a decision about which inputs it's allowed to consume, and if that snapshot can shift after approval, the authorization can be correct while the resulting behavior isn't.

Two events sharing an action type and a label name are not the same event; they can belong to different actors and trust levels even when every field looks identical.

A role check reviewed in isolation ("can this role trigger the workflow") misses the more useful question: what can a role that fails it still influence once a stronger role has already passed.

Disclosure timeline

Date	Event
August 5, 2026	Report submitted to Anthropic through HackerOne (#3918594)
August 13, 2026	Anthropic validated the issue, assigned High severity, CVSS 4.0 score 7.5
August 14, 2026	Bounty of $XXXX awarded
August 24, 2026	Editorial cutoff; report still triaged and private, no confirmed fixed version

Checking your own exposure

Start by seeing whether your workflow even uses this trigger pattern:

grep -rn -E "anthropics/claude-code-action|issues.*labeled|types:\s*\?labeled" .github/workflows/

You're in scope if your workflow triggers on issues.labeled with a Claude trigger label, runs in tag mode or otherwise grants workspace edits plus commit and authenticated push, and hands the job a write-capable token.

Anyone with GitHub's triage role, or any other sub-write role, can add and remove labels freely without writing code, generating the newer same-label event this bug depends on.

Until a fixed version is confirmed, restrict who can apply your Claude trigger label to write-and-above roles, treat anything a label-triggered run commits or pushes as unreviewed until a human looks at it, and keep downstream CI or deploy steps from auto-consuming those commits.

Where this leaves things

Claude Code Action's write-permission gate worked exactly as intended: it rejected the triage collaborator's own attempts to start a run, every time. The vulnerability sat one layer deeper: an already-authorized job later reconstructed its own trigger boundary from mutable history, and accepted a newer event belonging to the very principal it had just rejected.

The invariant here is simple to state and easy to violate: the event that defines a privileged agent's input boundary has to be the same event that authorized the run. Keep that identity intact, and later activity, however legitimate on its own, can't quietly rewrite an earlier authorization decision.

This was originally published by CodeAnt AI's Security Research Team. Read the complete breakdown here →

Escaping Claude Code's Sandbox: A TOCTOU Bug That Let Repo Code Overwrite Host Files

Amartya Jha — Mon, 31 Aug 2026 09:08:39 +0000

A parent-directory swap timed against a permission check let sandboxed repo code redirect a host-owned file write. CVSS 7.7, High.

HackerOne #3882177 · Claude Code 2.1.217, macOS arm64 · CVSS 4.0 score 7.7, High

Sandboxing runs on a simple promise: code inside it cannot reach outside it. Claude Code, Anthropic's coding agent, keeps that promise on macOS by boxing in Bash and everything it spawns, while leaving one door unlocked: a trusted editor process that applies the file changes Claude has permission to make.

We at CodeAnt AI Security Research tested whether that door could be reached from the wrong side of the sandbox. It could. A process confined entirely to the Bash sandbox got the trusted, host-owned Edit tool to overwrite a file the sandbox had already been denied direct access to. No outside-write approval appeared anywhere, and no permission check failed. The file simply changed.

Two kinds of trust sharing one filesystem

Claude Code splits authority during a session. Bash commands and their children run inside an OS-level sandbox with restricted filesystem access, so a repository's tests and builds can execute without full run of your machine. Built-in tools like Edit run in the trusted host process, the part actually allowed to touch your project.

Permissions decide whether Claude may call a tool at all. Sandboxing then restricts what Bash and its descendants can do at the OS level regardless of permission. In acceptEdits mode, edits auto-approve only inside the working directory; Seatbelt enforces that boundary for sandboxed processes, which is why a direct outside write returns EPERM.

None of that is the problem. The problem sits one layer up: the assumption that the file a permission check looked at is still the file the trusted writer touches a moment later.

A file path is a set of directions, not a destination

A path like /workspace/project/config.json isn't a pointer to one fixed object. It's a sequence of instructions: enter this directory, then this one, then open this file. Every step resolves fresh, at the moment something reads it.

Change one directory partway through that walk, without touching the final filename, and you change where the whole path ends up. Turn project into a symlink pointing elsewhere, and the same string now means something entirely different.

That's a time-of-check-to-time-of-use problem (TOCTOU for short): a gap between when something is verified and when it's used, wide enough for the underlying object to change in between. Claude Code's Edit tool had exactly that gap.

Where the two checks stopped agreeing

Static analysis of Claude Code 2.1.217's embedded JavaScript showed how Edit authorizes and writes a file, in equivalent pseudocode:

checkParentResolutions(target);
await mkdir(dirname(target), { recursive: true });
await replaceFile(target, content);

The tool checks the target's parent directories, checks again to catch ordinary symlink swaps, creates any missing directories, then writes the file.

That second check narrows the window for simple symlink substitution but doesn't close it. It only compares path strings at one instant, never binding authorization to a stable directory handle or inode. And the recursive mkdir call, which takes real wall-clock time, runs after that last check and before the write. That's the gap.

Turning an ordinary developer workflow into the trigger

We didn't want to assume a repository could hand-pick an arbitrary Edit call, so we used a sequence any Claude Code user would recognize as normal:

A developer opens a repository they don't fully control.
They ask Claude to run the tests and fix whatever's failing.
Claude runs the repo's own test command inside the sandbox, exactly as designed.
A pretest step quietly launches a small helper process, still confined to the sandbox, and has it wait.
The test fails, reporting a missing fixture at a path that looks entirely ordinary.
Claude, being helpful, creates that fixture using its built-in Edit path.

The repository controls the test, the failure message, and the fixture path. It never has to guess what Claude would independently choose.

A simplified target: <workspace>/slot/signal/private/tmp/demo/outside/payload.txt. signal starts as an ordinary directory; next to it sits armed, already a symlink to /. The helper never leaves the sandbox: a direct outside write gets EPERM every time. Its only useful move: renaming two entries it already owns inside the project.

The swap itself

The helper needed to know exactly when to move. The signal is the mkdir call itself: the moment the first missing directory gets created, Claude Code's final resolution check has already run and passed.

At that instant it calls renameatx_np with RENAME_SWAP, exchanging two directory entries atomically:

before: signal = ordinary directory, armed = symlink to /
after:  signal = symlink to /, armed = ordinary directory

The untouched, textually identical target path now resolves somewhere else entirely. Effective target: /private/tmp/demo/outside/payload.txt.

Claude Code's host-side writer, unrestricted by the sandbox, finishes exactly as it was going to: creates a temp file, renames it over the target. It has no reason to suspect anything changed. The sandboxed helper never touched the outside file itself. It only flipped an entry it already owned.

Only the last step of the path was actually guarded

Claude Code's writer does refuse to follow a symlink in the final path component, a genuine defense that stops a simpler attack cold.

It doesn't help here, because this race happens on an ancestor directory, not the final component. Guarding only the last link in the chain does nothing to guarantee the earlier links stayed the same object they were when permission was granted.

The permission system reasoned about a string and a resolution it observed once. The writer, later, walked that same string again and got a different answer. That mismatch is the entire vulnerability.

Proving it beyond a single lucky run

We built the reproduction to leave zero ambiguity about which boundary was crossed: isolated canary files, a throwaway home directory, a deterministic local model fixture, and no Anthropic credentials or live services involved.

Five variations, each changing exactly one property, separated the bug from expected behavior. Each ran three consecutive times, clean every time:

Scenario	Outcome	What it proves
Direct `Edit` call to a path outside the workspace	Denied	The permission layer correctly recognizes outside writes
Sandboxed helper tries writing the outside canary directly	`EPERM`	Seatbelt correctly blocks the attacker from the real target
Same directory layout, swap never triggered	Canary untouched	The path is safe as long as object identity doesn't change
Swap timed against the `mkdir` signal	Canary overwritten, zero permission denials logged	The host writer crossed the workspace boundary
A sibling dev project watched by an autoreloader	Modified source executed	An ordinary downstream tool turns the overwrite into execution

What this actually gets an attacker

With this primitive, a malicious repository, a compromised dependency, or a prompt-injected command running inside the Bash sandbox could get the trusted host process to overwrite an attacker-chosen, user-writable file anywhere outside the workspace: modifying sibling projects, tampering with build configuration, corrupting files CI reads downstream, and in some cases running arbitrary code, when something already present picks up the changed file on its own.

To be precise: this isn't an unconditional remote-code-execution bug. Getting from "overwritten" to "executed" needs an existing consumer already watching that location. On its own, the proven impact is arbitrary modification of a file outside the authorized workspace.

Anthropic rated the report High, CVSS 4.0 score 7.7:

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Why checking twice wasn't enough

The root cause is an authorization-to-use binding failure: the identity authorized at time T1 isn't the identity actually used at time T2. Rechecking the path narrows that gap but can't close it, since any later step that takes real time hands an attacker another window.

We also found the identical check-then-mkdir-then-write ordering in Claude Code's Write tool during static review. We're flagging the pattern, not claiming a second confirmed exploit.

Fixing it properly

The durable fix ties authorization and the eventual write to the same filesystem objects, not to a string re-resolved twice:

Open the trusted workspace root once and hold its descriptor for the whole operation.
Walk every ancestor relative to that descriptor using openat-style calls, never by re-resolving the full path.
Open each directory with O_DIRECTORY | O_NOFOLLOW, keeping descriptors alive until the write completes.
Create missing directories with mkdirat, relative to an already-verified parent.
Perform the final write with openat and renameat, not plain pathname operations.
If a component must be reopened across an async gap, verify its device and inode identity first.
Apply the same pattern everywhere this boundary shows up: Edit, Write, and any shared helper.

A pathname recheck before the final write is still worth having as defense in depth. It just can't be the only defense.

The broader lesson for agentic tools

Sandboxing a process doesn't remove its ability to influence what a privileged process does next. It can still shape diagnostics, file paths, and filesystem state the trusted side later consumes.

A pathname is not a durable identity; it's a recipe re-executed on demand. Any system that authorizes based on one resolution and acts on a later one needs to preserve object identity across that gap, not just recheck the string.

The strongest proof here was the contrast between a write that returned EPERM and a write, moments later, from the trusted side, that succeeded against the same target.

Should you worry about this right now

Check your version first: claude --version. This finding was reproduced on Claude Code 2.1.217, macOS arm64. Confirm affected and fixed ranges directly with Anthropic.

You're in the risk zone if: you're on macOS, you let Claude run repository commands in the Bash sandbox while using the built-in Edit/Write tools, you run in acceptEdits mode, and you regularly open repositories you don't fully trust.

Until a fixed build is confirmed, prefer explicit per-edit approval over acceptEdits for code you don't control, and watch for sibling projects or build watchers running alongside your workspace, since that's what turns an overwrite into execution.

The takeaway

The invariant this bug violated is easy to state and hard to implement everywhere it needs to hold: the object that receives a write has to be the same object, reached through the same verified chain of ancestors, that the permission system actually authorized.

If a system checks a path once and follows that same path again later, an attacker who can move what's underneath the path (without touching the string itself) can walk past every check while each one still reports success.

This was originally published by CodeAnt AI's Security Research Team. Read the complete breakdown here →

CVE-2026-71511 · Read a member's card, receive their password hash

Amartya Jha — Tue, 25 Aug 2026 09:20:02 +0000

CVSS 6.5 · Sensitive data exposure (CWE-200) · Fixed in Dolibarr 24.0.0

Every reply is supposed to pass a redactor that blacks out secrets. The Users redactor blacks out the password. The Members redactor, same job, next desk, forgot that one line, and hands the password verifier out with the card.

The attack in six steps

Every API reply runs through a "cleaner". Its job is to strip secrets before anything is sent back.
Line the two cleaners up side by side. The one for users against the one for members. (this is the break)
The Users cleaner removes the stored password hash. Exactly as it should.
The Members cleaner doesn't. One missing line, doing the identical job one desk over.
A "read members" key receives every member's password verifier. And from the list route, all of them at once.
Confirmed live, not a placeholder. Matched to the database, and it validated the real password. → credential exposure.

Before an application sends any record back to a caller, something has to decide what to leave out. Passwords, keys, the private machinery of an account, all of it is supposed to be stripped on the way out, by a step whose only job is redaction. When that step is thorough, you never think about it. When it isn't, secrets walk out in plain sight.

This is the story of two of those redactors, doing the same job for two similar kinds of record, where one remembered to black out the password and the other simply didn't, and how that one missing line handed every member's password verifier to anyone allowed to read a member card.

It is a simple example of how sensitive data exposure can happen inside an otherwise legitimate API response. The endpoint itself works as designed. The problem is that the Dolibarr security check responsible for removing sensitive credential data was incomplete.

Found by holding two things side by side

This finding didn't come from a clever attack. It came from comparison. Dolibarr redacts a user record and a member record with two separate pieces of code meant to do the same thing. So we put them next to each other and read them line for line.

The user redactor removed the stored password verifier before sending, exactly right. The member redactor, doing the identical job one desk over, didn't. One missing line, in one of two near-twin functions.

This is the kind of issue that can be missed by a straightforward application security assessment. Nothing needs to be injected or bypassed in the traditional sense. The vulnerability appears when two pieces of code responsible for protecting the same sensitive data are compared and found to enforce different rules.

What that one line leaks

The consequence is not subtle. An account holding nothing more than the right to read members, an ordinary, widely-granted permission, receives, along with each member's ordinary details, the stored verifier for that member's password. And because the same gap sits on the route that lists all members, you don't get them one at a time. You get the whole set in a single reply.

We confirmed the value was the real thing rather than a harmless placeholder by matching it back to the database and checking it corresponded to the member's actual password. It was live.

For a security researcher or penetration tester, that distinction matters. This was not simply a field that looked sensitive in a source-code review. We verified that the API returned real credential material and traced it back to the underlying application data.

The whole pattern in one line

If you want the entire theme of this research compressed into a single example, it is this one. The safe way already existed. The correct redactor was written, working, and sitting a file away. The neighbouring code that did the same job just skipped it. Not a hard problem, not a clever oversight, just a copy that wasn't quite a copy.

That is what “split-brain authorization” looks like at its smallest: two places responsible for the same rule, quietly disagreeing, with no one comparing them until someone does.

What closes it

The fix in 24.0.0 brings the member redactor in line with the user one, so the stored password material is stripped before any member record is sent, from single-record and list replies alike.

The lesson is almost embarrassingly practical: when two parts of a codebase are supposed to enforce the same rule, the highest-value test is often not an exploit at all. It is reading them side by side and asking whether they actually match. One of them got it right. Diffing it against its neighbour is how you find the one that didn't.

This is also why effective application penetration testing combines testing the running application with understanding how security controls are implemented. A response can look perfectly normal while still exposing sensitive data if one authorization or redaction path behaves differently from its counterpart.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71510 · Ask enough yes/no questions and you know everyone's salary

Amartya Jha — Tue, 25 Aug 2026 09:18:01 +0000

CVSS 6.5 · Authorization oracle → blind disclosure (CWE-863 / CWE-200) · Fixed in Dolibarr 24.0.0

You can't see the salary column, but the search box will happily answer “is this person's salary above 50,000? yes or no.” Ask twenty smart questions and you've read the exact number without ever seeing it.

The attack in six steps

The user list has a search filter: you can narrow it by a column's value.
It's safe from SQL injection: the obvious attack was checked, and it holds.
The unasked question: which columns may you filter on?: the answer was any of them, including salary and the password hash. (this is the break)
Those columns are stripped from the reply: so you never actually see the value.
But "filter salary above X" returns a row, or nothing: that single yes/no is a leak.
Binary-search the answers to the exact number: salaries recovered blind, plus a case-folded image of the hash. → blind disclosure.

There is a whole class of secret you can steal without ever being shown it. You don't need the system to hand you the value. You only need it to answer yes-or-no questions about it, honestly, as many times as you like. Twenty good questions are enough to pin down almost any number.

This is the story of a search box that would answer exactly those questions about columns it was supposed to keep hidden, salaries, and even the stored password verifier, and how a low-privilege account read them precisely, blind, without the system ever displaying a single one.

It is the most subtle finding in the set, because nothing here looks broken. No error, no leak on the screen, no obvious hole. Just a search filter answering a question it should have refused to consider.

This is the kind of web application security issue that can slip past a straightforward vulnerability scan: the search feature is not injectable, the response does not expose the sensitive field, but the application's authorization logic still lets a low-privilege user interrogate it.

The obvious attack, and the one underneath it

The user list has a search filter, so you can narrow the list by a column's value. The reflex is to test it for injection: can you break out of the query and run your own? We checked, and the answer was no. On that front it is safe, and a lot of reviews would stop there satisfied.

The second, quieter question is not about breaking the query at all. It is about authorization: which columns are you even allowed to filter on? The answer turned out to be all of them, including the salary fields and the password verifier that the results are so careful never to display.

This is where security testing has to go beyond checking whether an endpoint returns the expected response. A penetration test also needs to ask whether a low-privilege user can use an otherwise legitimate feature to access information they are not authorized to interrogate.

Turning a filter into a yes/no oracle

Those columns are stripped from what comes back, so you never see a salary in the list. But you can still filter on one. And a filter you can apply to a hidden column is a question the system will answer: ask it to show everyone whose salary is above fifty thousand, and either a matching row comes back or it doesn't. Row or no row. Yes or no.

That single bit is the whole leak. Ask “above 50,000?”: no. “above 25,000?”: yes. “above 37,000?”: and so on, each question halving the range that's left. In a couple of dozen questions you have squeezed the exact figure out of a value the screen never showed you. Point the same technique at the stored password verifier and you can walk it out piece by piece.

The honest part: what it is not

A responsible finding has to say where the danger stops, and we were careful to. The password material you can recover this way is not a usable key to log in with: Dolibarr stores it in a form it will not accept back as a login, and the recovered image is case-folded rather than exact. So this is a serious disclosure, real salaries, real hidden fields, read blind, but it is not, by itself, account takeover. We tested that boundary, confirmed it held, and wrote the disproof into the report so a reviewer could see we had actually checked rather than assumed.

That distinction matters for trust. It is easy to inflate a finding by implying the worst. It is more useful, and more credible, to show exactly how far it goes and exactly where it stops.

Why it's easy to miss, and what closes it

This is the kind of hole endpoint-by-endpoint testing walks straight past. The filter isn't injectable. The response doesn't leak. Nothing throws an error. The only thing wrong is that a question was allowed which never should have been, and you only see it if you ask, of a search feature, not “can I break this,” but “which fields am I permitted to ask about.”

The fix in 24.0.0 restricts which columns the filter will accept, so hidden fields can no longer be interrogated through the back door of a yes/no search. The lesson is to treat a filter as an authorization surface, not just an injection surface: every column you let a caller filter on is a column you are willing to answer questions about, one bit at a time.

This is also why security research needs to look beyond individual endpoints. In this case, the issue was not an obvious injection vulnerability. It was the interaction between filtering, authorization and sensitive fields, which is exactly the kind of behaviour that deeper application security testing can uncover.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71509 · Approve your own expenses — and your whole team's

Amartya Jha — Tue, 25 Aug 2026 09:16:07 +0000

CVSS 6.5 · Approval / access-control bypass (CWE-862) · Fixed in Dolibarr 24.0.0

The big “Approve” button correctly needs a manager. But the plain “edit this report” form lets you type approved and name anyone as the approver, straight into the fields, with no manager required.

The attack in six steps

Expense reports need a second person to approve: basic separation of duties.
The dedicated Approve button checks for it: the front door is genuinely locked.
But the generic "update report" route writes the same fields: status and approver, set directly. (this is the break)
Nothing checks the approver differs from the author: or that you hold the approval right at all.
Mark your own claim approved and name anyone as approver: from an account that can only file claims.
Your claim, and a subordinate's, enter the payable queue: the second signature never happened. → self-approved payouts.

Expense approval is a textbook example of separation of duties: the person who files a claim must not be the person who approves it. That one rule is what stands between a company and an employee quietly signing off their own reimbursements. Dolibarr knows the rule, and the obvious button that approves a report enforces it properly.

This is the story of a second, plainer path that writes the very same fields the Approve button does, without asking whether the person approving is the person who filed.

The front door is locked. The side door was left open, and it leads to the same room.

The question with an obvious answer, and a real one

With any approval workflow, the first question to ask is the classic one: can the same person file a claim and approve it? We asked it of the dedicated Approve action, and the answer was a reassuring no. That action checks for the right permission, exactly as it should. A shallow security test stops here and calls it safe.

The real answer lived one path over. Alongside the Approve button, Dolibarr has a generic “update this expense report” path, the kind of catch-all that lets you edit a report's details. And that path lets you write the report's status and its approver directly, as if they were ordinary fields like a date or a note.

This is where API security testing and business logic testing matter. An endpoint can correctly protect its dedicated privileged action while another route exposes the same state change without enforcing the same authorization rules.

Signing your own name on the approval line

So an account that can only file claims opens the generic update path, sets the status to approved, and writes itself, or anyone it likes, into the approver field. Nothing checks that the approver differs from the author. Nothing checks that the account holds the approval right at all. The claim moves into the payable queue, approved, with a name on the approval line that the filer chose.

We did it to our own claim, and then to a subordinate's, from an account that was never supposed to approve anything.

Why a correct check isn't enough

The uncomfortable lesson here is that the Approve button being correct bought almost nothing. A control is only as strong as the weakest path that can reach the same state. If one carefully guarded action sets a field, and a second, generic action sets the same field with no guard, then the second action is the real security boundary, and it is wide open.

The damage is money leaving on approvals that never happened. In a company relying on Dolibarr to enforce the two-person rule on reimbursements, this quietly dissolves it: a single employee can file and approve, or approve for others, and push claims into the queue that pays them.

For Dolibarr security testing, this is an important distinction. Testing only the intended approval workflow can miss a business logic vulnerability exposed through a generic update endpoint. Effective penetration testing has to trace sensitive state changes across every route that can create them.

What closes it

The fix in 24.0.0 brings the generic update path under the same rule the Approve action already enforced. The status and approver fields can no longer be written freely, and the separation between filing and approving holds on every path, not just the obvious one.

The takeaway generalises to any workflow with a privileged step: find every path that can write the state, not just the one built for it. A locked front door means nothing while a back-office form writes the same fields with no check at all.

This is also the kind of authorization gap that a web application penetration test should look for: not just whether a user can access an endpoint, but whether they can use an alternative endpoint to reach a privileged application state they were never meant to control.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71508 · Set your own salary — and the receipt hides it

Amartya Jha — Tue, 25 Aug 2026 09:14:38 +0000

CVSS 6.5 · Mass assignment on payroll fields (CWE-915) · Fixed in Dolibarr 24.0.0

The form that updates your profile refuses to let you change your job title, but leaves “salary” wide open, then shows you a receipt with the salary line blanked out, so it looks like nothing happened.

The attack in six steps

The profile-update route copies your fields onto your record: standard API behaviour.
It blocks a short list of obvious secrets: but salary, bonus and cost rates aren't on it. (this is the break)
Send a new salary for your own account: from a user with zero payroll permissions.
The write succeeds, but the reply hides it: the response omits the field it just changed, so a quick security test looks like nothing happened.
Read the database before and after: the only way to see the new number is really there.
It flows into the official payroll export: an employee rewrote their own pay. → payroll tampering.

Payroll is one of the few things in a company everyone agrees must be locked down. What each person earns, salary, bonus, the internal rates used to cost their time, sits behind a permission only HR and finance are meant to hold. The interface Dolibarr shows a human respects that boundary completely.

This is the story of how, underneath that respectable interface, the route that saves your own profile would quietly write your own salary, then hand you back a receipt with that very change hidden, so a casual API security test would swear nothing had happened.

It is a mass-assignment vulnerability, the same family as the admin-takeover one, but with a nastier twist: this one covers its tracks.

The short block-list that forgot the important fields

When you save your profile, the route takes the fields you sent and writes them onto your record. It does try to be careful. It keeps out a short list of obviously dangerous fields. But a block-list is only ever as good as its imagination, and this one's imagination stopped short. Salary, bonus and the internal cost and daily rates, the four fields that actually decide what someone is paid, were not on it.

So an ordinary user, holding no payroll permission at all, edits their own profile and includes a new salary. The route writes it. There is no check that this particular field belongs to a locked-down part of the system. It is simply another field in the pile, and the pile gets written.

This is the core of the CWE-915 mass-assignment issue: the API accepts fields based on what has not been explicitly blocked rather than limiting the request to fields the caller is actually authorized to modify.

The silence that hides it

Here is what makes this one genuinely sneaky. The reply you get back is run through a “cleaner” whose job is to strip sensitive fields before sending anything out. So the response leaves the salary line blank, not because the write failed, but because the reply is not allowed to show it.

The effect is that a quick API penetration test looks like a clean rejection. You send a new salary, the answer comes back with no salary in it, and every instinct says “nothing changed.” The write succeeded; the receipt just doesn't mention it. That gap between what happened and what the response admits is exactly where a bug like this hides for a long time.

Following the number all the way through

Because the response gives nothing away, the only way to catch the full impact was to stop trusting it. We read the database directly, before and after: the new salary was really there, written by an account with zero payroll rights. Then we followed that number where it counts, into the official payroll export, the report finance actually uses, and there it was too.

That is the difference between “a field can be set” and “an employee can rewrite their own pay and have it flow into the payroll run.” The first is a curiosity. The second is the finding.

For Dolibarr security testing, that distinction matters. A penetration test cannot stop at whether an API returns 200 OK or 403 Forbidden. It has to establish what the request actually changed, what permissions the caller had, and where that changed data flows next.

What closes it

The fix in 24.0.0 stops treating payroll fields as ordinary profile fields: they now require the permission that governs pay, rather than riding in on a self-profile update, and the change is no longer hidden from the very response that would let someone notice it.

There are two lessons stacked here. First, a block-list of “dangerous fields” is the wrong shape. It fails silently the moment someone adds a new sensitive field and forgets to list it; an explicit list of the fields a caller may set fails safe instead. Second, hiding a value in the response is not the same as protecting it in the database. A write you can't see in the reply is still a write.

For developers and security teams, this is also a reminder that API authorization testing needs to cover individual fields, not just endpoints. An endpoint can have authentication and authorization checks and still expose a sensitive field through mass assignment.

The fix. Upgrade to Dolibarr 24.0.0, that closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71507 · Change one number, and the payroll run pays you

Amartya Jha — Tue, 25 Aug 2026 09:12:30 +0000

CVSS 6.5 · Object-level auth bypass → SEPA payment redirection (CWE-639) · Fixed in Dolibarr 24.0.0

You can't see a supplier's account, but you can quietly edit the bank number the company will pay. When payday's batch is generated, your account is sitting inside it as the payee.

The attack in six steps

You can't even read the three suppliers. They're off-limits to your low-privilege account.
But the bank-detail write route skips that ownership check. The same gap, on the field that matters most. (this is the break)
Rewrite their bank numbers to accounts you control. Three IBANs, swapped for three of your own.
The business generates its payment batch. The routine SEPA file it hands the bank.
Your accounts are the creditors in a real payment file. Several thousand euros, in a byte-for-byte legitimate run. → money redirected.
We stopped at the generated file. Never sent it, but the attacker's account was already inside a live payment instruction.

Once a month, or once a week, a business does something almost mechanical: it generates a payment file and hands it to its bank, and the bank pays every supplier on the list. That file is one of the most consequential things the whole system produces. It is money leaving the building, and almost nobody reads it line by line. They trust that the numbers in it came from supplier records set up long ago.

This is the story of how an attacker who could not even read those supplier records rewrote the bank details inside them, so that when the next payment run was generated, three of the creditors were accounts the attacker controlled.

The same missing authorization check we found across Dolibarr shows up here on the one field where it hurts most: the destination of a payment.

This finding is a clear example of broken object-level authorization (BOLA) in an API: the application checks whether an account can perform a type of action, but fails to verify whether it can perform that action on the specific supplier record.

The write that shouldn't have worked

The attacker's account is low-privilege by design. Ask it to read the three target suppliers and it is refused. It has no business seeing them. On the read side, Dolibarr holds the line.

But editing a company's bank details goes through a different API path, and that path skips the ownership check its read sibling performs. It asks whether you are the sort of account that can edit company records at all, not whether these companies are yours. So the attacker rewrites the account numbers of three suppliers it was never allowed to look at, swapping in three accounts of its own.

This is the kind of authorization gap that API penetration testing is designed to uncover. A basic permission check can look correct while still allowing a low-privilege user to modify another object's sensitive data. Testing the read and write paths separately exposed the difference.

Chasing the value to where it actually goes

A changed bank number, on its own, is the kind of thing a busy reviewer shrugs off. “So a field can be edited, so what.” The move that turned this from a shrug into a serious security finding was refusing to stop at the write, and asking the only question that matters: where does this value actually go?

It goes into the payment file. When the business next generates its supplier-payment batch, the routine SEPA payment file it hands its bank, Dolibarr reads each supplier's default bank account and writes it into the file as the creditor. The three accounts now sitting in those supplier records are the attacker's. So the generated batch, a file that is byte-for-byte a legitimate payment run, carries the attacker's accounts as the people about to be paid, for several thousand euros.

Where we stopped, and why it still has teeth

We stopped at the generated file. We never submitted it to a bank, and no money ever moved. That line is not one a security test gets to cross. But the finding does not need money to have moved to be real. The attacker's account was already inside a live payment instruction, indistinguishable from a legitimate one, waiting for the ordinary approval such files get on their way out the door.

Whether that last step would succeed in the real world depends on a company's own controls, whether a human reconciles the file, whether the bank checks that the account name matches the account number. Those are real backstops. But they are backstops against a file that should never have contained an attacker's account in the first place. The boundary meant to prevent this, you may not touch suppliers you don't own, was already bypassed several steps upstream.

For Dolibarr security, the important lesson is that protecting a payment workflow cannot stop at the final payment-generation step. The supplier data feeding that workflow needs the same object-level authorization controls as the payment action itself.

What closes it

The fix in 24.0.0 brings the bank-detail write under the same ownership check the rest of the supplier record already enforced, so an account that cannot read a supplier can no longer quietly edit where that supplier gets paid.

The lesson we wrote down is about following data, not just guarding entry points. A tampered field is only as harmless as the least-careful place it eventually flows to. Ask, for every value a low-privilege caller can change, where does this end up? This one ended up in the file that moves the money.

That is also why effective application security testing needs to trace an attack beyond the first successful request. The question is not only whether an API lets an unauthorized change through. It is what that changed value can eventually control.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71506 · The wrong key on the lock

Amartya Jha — Tue, 25 Aug 2026 09:10:19 +0000

CVSS 6.5 · Wrong-permission authorization (CWE-863) · Fixed in Dolibarr 24.0.0

The button labelled “delete a draft invoice” is wired to the vault that holds recorded payments. Press it and money that was actually paid shows up as owed again.

The attack in six steps

Deleting a payment should need the "manage payments" right. A specific permission for a specific role.
But the route checks the "delete invoices" right instead. A different key for a different job. (this is the break)
The attacker holds only "delete invoices". We dumped its real rights first to prove it.
Delete a real, recorded customer payment with no check on which invoice it belongs to.
The payment row simply vanishes. An invoice's "paid" total is just the sum of its payments.
A fully-paid invoice flips back to "owed". Phantom debt on the books. → corrupted accounts.

In an accounting system, a recorded payment is not a note you can casually erase. It is part of the ledger, the line that says this invoice was settled, this money arrived. Deleting one should be a careful, privileged act, gated behind the specific right to manage payments and handed only to the people who reconcile the books.

This is the story of a route that guarded that destructive act with the wrong key, and how an account that could only ever “delete invoices” ended up destroying recorded payments and writing phantom debt onto the books.

The two permissions sound close enough that the mix-up is easy to make. “Delete invoices” and “manage payments” are different rights, handed to different roles for different reasons. The delete-payment route checked the first when it should have checked the second, a swapped lock on a door that leads somewhere it shouldn't.

Proving the account wasn't secretly privileged

Deleting money is destructive, so before anything else we did the unglamorous, essential step: we dumped the test account's actual rights and wrote them down. That matters, because the easiest way for a finding like this to be waved away is “well, your account probably had extra permissions.” It did not. It held the right to read and delete invoices, and nothing to do with payments at all.

Then we pointed that account at a real, recorded customer payment and asked Dolibarr to delete it. Two questions should have stopped the request. The first, “do you hold the right to manage payments?”, was never asked; the route checked the invoice-deletion right instead. The second, “are you even allowed to touch the specific invoice this payment belongs to?”, was not asked either. The payment simply vanished.

That distinction is at the heart of effective authorization testing. It is not enough to confirm that an API checks a permission. Security testing has to establish that the application checks the permission that actually governs the requested action.

Where the phantom debt comes from

Here is the quietly nasty part. In Dolibarr, an invoice's “paid” figure is not stored as a fact of its own. It is the sum of its payments. Remove one, and the sum drops, automatically, silently, with no separate record that anything was deleted.

So a fully-paid invoice, the moment its payment is destroyed, flips back to showing an outstanding balance. On the screen, and in every report that reads from it, money that genuinely arrived now looks owed. Delete the payments across a batch of invoices and you have manufactured debt that never existed, on books that will be trusted by whoever reads them next.

Why it lands harder than it looks

On paper this is a medium-severity bug, and in isolation that is fair. It does not hand anyone the keys to the system. But sit with what it does to a set of real books. Payments disappear with no audit trail. Paid invoices reopen. Reconciliation, the monthly ritual of matching what the bank says against what the system says, stops adding up, and the people doing it have no deleted-payment record to point at, because there isn't one.

The proof we kept coming back to was almost mundane, and all the more convincing for it: watching an outstanding balance climb on an invoice that had been paid in full, driven entirely by an account that was never supposed to be anywhere near the payment ledger.

This is exactly the kind of application security issue that can look harmless when reviewed only at the endpoint level. The permission check appears to be there, but it governs the wrong operation. A penetration test that exercises the action with deliberately mismatched privileges can expose that gap before it reaches production.

What closes it

The fix in 24.0.0 is exactly what the description implies: the delete-payment route now checks the right that actually governs payments, not the one that happens to sit nearby, and it verifies access to the specific record before acting.

The general lesson is one every codebase can use. When a destructive action is guarded, check that the lock on it is the right lock, that the permission being tested is the permission that governs the thing being done. A guard that checks a plausible-but-wrong right feels like security and is worse than none, because it looks solved.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71505 · The read desk checks your ID. The write desk doesn't.

Amartya Jha — Tue, 25 Aug 2026 09:07:33 +0000

CVSS 8.1 · Broken object-level authorization (CWE-639) · Fixed in Dolibarr 24.0.0

The clerk who shows you a file first checks it's yours. The clerk who resets the password on that file never checks, so you can change the lock on a company you're not even allowed to look at.

The attack in six steps

Try to read a company you don't own. Your low-privilege key is correctly refused. (403 Forbidden)
Call the write route instead. The path that sets that company's customer-portal password. (this is the break)
It only asks: can you create companies? Never "is this company yours?"
Set the portal password to one you choose. The write lands on a company you can't even see. (200 OK)
Sign into the customer portal as them with the password you just set.
Read their invoices. Records you were forbidden to read directly. → another company's private billing.

Dolibarr can hand each of a company's customers a small self-service portal, a place to log in and see their own invoices. Which means Dolibarr is holding, on behalf of every one of those customers, the keys to a private account. The entire point of that arrangement is that one customer can never see another customer's invoices.

This is the story of a low-privilege account that could not so much as look at a company's record, and used a second, unguarded door to reset that company's portal password, log in as them, and read their invoices anyway.

The account in question is deliberately weak. It can create companies; it cannot read the ones it does not own. When it tries to read the victim's record, Dolibarr does exactly the right thing and refuses. On the read side, the walls are solid. The mistake is on the write side.

The door that checks, and the door that doesn't

Before this finding we had already gone over the customer-portal read paths, the ones that hand information back, and found them careful. Ask to read a company you do not own and you are turned away, per company, correctly. It would have been easy to tick the box and call the whole area safe.

The discipline that paid off was refusing to assume the write paths behaved the same way. Reading and writing are different doors, even when they lead to the same room, and they have to be tested separately. That distinction is central to good API security testing: an authorization control on a read endpoint does not prove that the corresponding write endpoint enforces the same boundary.

The write path in question sets a company's portal password. And it asks a much lazier question at the entrance. Instead of “are you allowed to touch this company?”, it asks only “are you the kind of account that can create companies at all?” The attacker's account can create companies, so it sails through. It never has to prove the company is its own.

Setting the lock on a door you can't see

So the attacker takes a company it was just told it may not read, and writes a brand-new portal password onto it. Dolibarr accepts the write. Then the attacker walks around to the customer portal, signs in as that company with the password it just set, and the invoices, the ones meant to be private to that customer forever, open up on screen.

The read wall was never breached. It was simply walked around, through a write path that forgot to ask the same question.

That is the defining shape of a broken object-level authorization (BOLA) vulnerability. The API knows that access should be restricted at the object level, but one route checks only a broad permission instead of whether the caller is authorized to access the specific company identified in the request.

Why this shape keeps happening

This is one of the cleanest examples of the pattern that runs through most of our Dolibarr security research. Enforcement on the way in tells you nothing about the way out. A team hardens the read paths, watches them hold, and reasonably assumes the feature is safe, while a sibling write path, added at a different time by a different hand, checks a weaker condition, or none at all.

The impact is concrete and it compounds. Every company with a portal account is exposed, not just one. An attacker who can create companies, a low bar in many deployments, can reset portal passwords across the whole customer base and read each customer's private billing in turn. For a business whose customers trust it to keep their invoices to themselves, that is exactly the kind of quiet authorization vulnerability that does lasting damage.

This is also why BOLA belongs in API penetration testing rather than being treated as a purely theoretical code issue. The important question is not only whether an endpoint contains an authorization check, but whether the check actually protects the specific object the request is trying to modify.

What closes it

The fix in 24.0.0 makes the write path ask the same per-company ownership question its read sibling already asked, the same check, applied to both doors instead of one.

The takeaway we wrote down afterwards is worth repeating: test read and write as separate doors, always. A boundary that is enforced in the place you happen to look first is not proof of a boundary. It is proof of one door.

The fix. Upgrade to Dolibarr 24.0.0, that closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71504 · The membership desk that could reset the admin's password

Amartya Jha — Tue, 25 Aug 2026 09:05:51 +0000

CVSS 8.3 · Mass assignment (CWE-915) · Fixed in Dolibarr 24.0.0

The front desk refuses to change the CEO's password. But the membership clerk's window, which nobody thought to lock will happily do it, if you slide the very same form through it.

The attack in six steps

The front door says no: Ask the account interface to change the admin's password and it refuses. (403 Forbidden)
Send the identical change to the membership desk: A completely different window into the same data. (this is the break)
It checks only one thing: can you add members?: A routine permission that has nothing to do with login accounts.
It accepts every field you sent: Including two that quietly belong to the linked account: the target and the new password.
Point them at the administrator: The admin's stored password is overwritten with one you chose. (200 OK)
Log in as admin with your password: Same instance, same key, opposite answer. → full takeover.

Every serious application guards one rule more carefully than any other: who is allowed to change a password. Get that wrong and everything else, every permission, every record, sits downstream of a single mistake. Dolibarr guards it well. Ask its user-management screen to change the administrator's password without the right to do so, and it says no, flatly.

This is the story of how the same request, same instance, same key, same target, gets a yes simply by being posted through a different window.

Dolibarr is the back office for a lot of small clubs, associations and companies. Alongside its login accounts, it has a separate feature for managing members: the people who belong to a club or association. Different feature, different screen, different permission. The person at the membership desk is trusted to add and edit members all day, and that was meant to be the whole of what they could do.

The bug is that the membership desk quietly has a spare key to the login accounts, and nobody noticed it was on the ring.

Two doors into the same room

The rule we applied over and over in this security research is simple: when one part of an app guards something, go and find every other part that can touch the same thing, and check the guard is there too. Applications grow in layers, and the second door into a room is the one that gets forgotten.

Dolibarr's account-management screen treats a password with the respect it deserves. Before it will change one, it checks that the caller actually holds the specific right to manage credentials. A membership key does not, so through that door the answer is a clean refusal.

The members screen is a different door into a database that, it turns out, overlaps. A member record can be linked to a login account. And when you create or edit a member, the members screen does something careless: it takes every field you sent it and writes it onto the record, no questions asked. It checks one thing at the entrance, “are you allowed to manage members?”, and then trusts everything that follows.

From an application security perspective, this is the dangerous shape of a mass-assignment vulnerability: a legitimate write endpoint accepts fields that belong to a more privileged part of the application's data model.

The two fields that don't belong

Buried in that pile of accepted fields are two that were never really member fields at all: one that says which login account this member is attached to, and one that says what that account's password should be.

So the attacker fills in a member form, points the “attached account” field at the administrator, sets the “password” field to a string of their choosing, and posts it to the membership desk. The desk checks that the caller can manage members, they can, and then dutifully writes the new password onto the linked account. The linked account is the administrator.

The same password change the front door refused a moment ago is now done, through a window that only ever asked whether you could file paperwork for a club.

What it costs

The instant that write lands, the real administrator is locked out. Their old password simply stops working. The attacker logs straight in with the password they picked. No cracking, no stolen session, no clever timing. One ordinary request from an account that holds nothing but membership permissions, and the whole system changes hands.

There is one soft edge worth being precise about. If a second administrator already exists, recovery is easy. If not, getting back in means an out-of-band reset from the database or the command line, which is why the availability impact is scored as a disruption rather than total destruction. Confidentiality and integrity, though, are at the top of the scale, because by this point the attacker owns everything.

And the permission that makes it all possible is one an administrator hands out without a second thought. “You can manage our members” sounds harmless. It is exactly the access you would give a volunteer registrar at a club. Dolibarr even lists Members and Users as separate, unrelated modules, so nobody granting the one imagines they are also granting the other. A leaked membership key, a compromised registrar, an over-trusted volunteer, any of them is now a path to full control.

What closes it

Dolibarr already had the correct behaviour written down in the account-management screen, which refuses credential fields outright and demands the password right before it will touch one. The fix in 24.0.0 brings the members screen under the same discipline: sensitive fields are rejected before they are ever written, the password right is required, and the quiet sync onto the linked account no longer fires by default.

The lesson outlives this one screen. An interface should never assume that every field a caller can send is a field they should be allowed to set. The durable fix is a short, explicit list of the fields each screen accepts, not a scramble to block each dangerous one after it is found. When one part of the code already gets a sensitive check right, the next part that touches the same data is not a fresh design problem. It is a copy you owe yourself.

That is also why API security testing needs to look beyond whether an endpoint has an authorization check. A permission can exist and still be applied to the wrong data, the wrong field, or the wrong route. Testing those alternate paths is what turns a code-level suspicion into a validated security vulnerability.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71503 · One link, opened once, mints a second admin

Amartya Jha — Tue, 25 Aug 2026 09:02:37 +0000

CVSS 9.3 · Reflected XSS (CWE-79), chained to admin creation · Fixed in Dolibarr 24.0.0

Think of a contractor's badge that, when scanned at reception, silently prints a second master key, and the guard hands it over, because the request came from inside the building.

The attack in six steps

A link that looks like ordinary work: A URL pointing at a routine admin setup page, with a tiny instruction hidden in the web address.
An admin opens it: It arrives by email, ticket or chat and looks like an internal settings page; nothing on screen changes.
The page runs the hidden instruction: It drops that address value straight into its own scripting, missing one safety step, so the attacker's snippet runs as code. (this is the break)
The script reads the page's own security token: The anti-forgery token Dolibarr prints into every page for itself; the injected script just reads it, no theft required.
It asks Dolibarr to create an admin: Using that token and the admin's own logged-in session, a create-user request that looks completely legitimate.
A second administrator now exists: With a password and API key the attacker chose, surviving after the browser closes. → full admin.

Dolibarr is the quiet software at the centre of a lot of small companies. It holds the invoices, the customer list, the supplier bank details, the payroll, the whole back office. The person who administers it can do anything: add users, change settings, read every record. So the single most valuable thing in the entire system is the administrator's account.

This is the story of how an attacker walks away with a second administrator account, one Dolibarr never knew it was creating, from a single link, opened once, by an admin who was only doing their job.

The link looks utterly ordinary. It points at an internal setup page, the kind of screen an admin opens a dozen times a week to add a custom field. Nothing on that page looks wrong. Nothing flashes. The admin glances at it and moves on. And in that glance, a new administrator quietly appears in the database, with a password and an API key the attacker chose in advance.

Here is the part we love about this one: the obvious version of the attack failed, and that failure is exactly what made the dangerous version possible.

The reflex that didn't work

When you find a bug that lets you run a snippet of code on someone else's page, the first instinct is boring and predictable: steal the login cookie, become that user. We tried. It came back empty.

Dolibarr, sensibly, hides its session cookie from scripts, a setting that tells the browser "code running on this page may not read this." So the textbook move was dead on arrival. On most days, that is where the story ends and the bug gets filed as low severity: yes, you can run a script, but there is nothing here worth taking.

From an application security testing perspective, this is an important distinction. Finding reflected XSS does not automatically tell you what the vulnerability can achieve. The real question is what security-sensitive actions the injected code can perform within the victim's authenticated session.

The moment it turns

Except there was something worth using, not stealing.

To protect its own forms, Dolibarr prints a small security token into every page. It is an anti-forgery measure: the app's own buttons read that token and send it back, so the server can tell a genuine click from a forged one. It is a good defence. But a token printed into the page for the page's own scripts to read is, by definition, readable by any script on the page, including the one the attacker just slipped in.

So the injected script does not need to steal anything. It reads the token sitting right there in the page, and then it does the single thing that token unlocks: it asks Dolibarr to create a new user, as the admin, from the admin's own logged-in browser. To the server it looks like the administrator calmly filling in the "add user" form. The browser attaches the admin's session automatically, because the request is going to the very same site it came from. The request came from inside the building, so the guard waves it through.

And no alarm sounds, for a mundane reason: a fresh Dolibarr install does not switch on the browser-level protection that would have refused to run the injected script in the first place. It is off by default, so nothing stands in the way.

What the attacker walks away with

The important thing about that new account is what it isn't. It is not a hijacked browser tab that vanishes when the admin logs out. It is a real administrator, a real row in the database, with a password the attacker chose and an API key the attacker chose. It stays there after the browser closes, after the laptop sleeps, after the admin goes home.

That one detail changes the entire clean-up. Picture the team noticing something odd and doing the sensible thing: reset the admin's password. It does not help. The attacker was never using the admin's password, they made their own account. And the API key on that account keeps working quietly in the background, reading the whole user directory through Dolibarr's own interface, long after everyone assumes the incident is closed.

There is a limit worth being honest about: some records, specific invoices, customers, payroll, stay behind Dolibarr's normal permission checks, which have no special "admins skip this" bypass. But a full administrator can grant itself any permission it likes with one more request, because simply being marked an administrator is enough to unlock that. So the limit is a speed bump, not a wall.

And it is not about one page or one feature. The vulnerable screen is built from a template Dolibarr reuses across 80 different pages. We confirmed the same trick on the Products, Agenda and Third-parties setup screens. Turning off one module only moves the unlocked door somewhere else.

Why it was there, and what closes it

The frustrating part is that Dolibarr already owned the tool that would have stopped this cold. It has a function whose entire job is to make a value safe to drop into a script, and it is used correctly elsewhere in the same codebase. This one screen simply never called it. The value from the web address was filtered on the way in, but filtering an input for a few bad characters is not the same as safely escaping it on the way out. One missed step, on one line, behind 80 pages.

Dolibarr 24.0.0 fixes it: the value now passes through the proper escaper before it ever reaches the page, and because the fix lives in the shared template, all 80 pages are protected at once. If you run an affected build, upgrading is the whole answer.

This finding is the odd one out in our Dolibarr research. The rest of that work is about permission checks that quietly go missing between two different doors into the same room. This one is an encoding mistake, not an access-control one, yet it earns its place for the same underlying reason: the safe thing already existed, one function call away, and a single screen skipped it.

For vulnerability research and penetration testing, that distinction matters. A source-code review can identify the unsafe sink, but testing the running application shows whether the flaw can actually be chained into a meaningful security impact.

The fix. Upgrade to Dolibarr 24.0.0, that closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings