CVE-2026-81505: Convoy Remote Code Execution Vulnerability

HIGH
Advisory Identifier: GHSA-p5vg-v7mj-f6q4
CWE-639
Published
Advisory Summary

CVE-2026-81505 is a HIGH remote code execution vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Convoy libraries in the Go ecosystem. The issue involves cross-tenant source idor leaks plaintext message broker credentials. Remediation is available by upgrading affected packages to version 0.9.3-0.20260724092134-1cc67cd16fb1.

CVE-2026-81505 at a Glance

CVE Identifier CVE-2026-81505
GHSA Identifier GHSA-p5vg-v7mj-f6q4
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product Convoy
Package Ecosystem Go
Published Date
Last Updated

How to Fix CVE-2026-81505

To remediate this vulnerability, upgrade all affected Convoy dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/frain-dev/convoy fixed: 0.9.3-0.20260724092134-1cc67cd16fb1
Upgrade github.com/frain-dev/convoy to 0.9.3-0.20260724092134-1cc67cd16fb1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/frain-dev/convoy

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-81505, inspect your project dependencies for Convoy:

inspect dependencies for github.com/frain-dev/convoy

Analyze the terminal output to locate any version of Convoy in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.9.3-0.20260724092134-1cc67cd16fb1), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In Convoy, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary frain-dev/convoy (all versions up to and including v26.6.2, no patch available) lets any authenticated caller who is authorized on at least one project read ANY OTHER project's "Source" record by ID via GET /api/v1/projects/{projectID}/sources/{sourceID} -- regardless of whether that Source actually belongs to the project named in the URL. The response includes the Source's full PubSub broker configuration in plaintext (AMQP/Kafka/SQS/Google credentials), with no redaction. ## Details `Handler.GetSource` (api/handlers/source.go) resolves the caller's authorization against the {projectID} in the URL via retrieveProject(), then calls `sources.Service.FindSourceByID(ctx, project.UID, sourceID)` (internal/sources/impl.go). That function accepts a projectID parameter but never uses it: func (s *Service) FindSourceByID(ctx context.Context, projectID, id string) (*datastore.Source, error) { row, err := s.repo.FetchSourceByID(ctx, common.StringToPgText(id)) ... } The underlying SQL query (internal/sources/repo/queries.sql, `fetchSourceByID`) has no project_id predicate at all: SELECT ... FROM convoy.sources AS s LEFT JOIN convoy.source_verifiers sv ON s.source_verifier_id = sv.id WHERE s.id = $1 AND s.deleted_at IS NULL So the {projectID} in the URL only gates "is the caller authorized to view *a* project" -- it never re-validates that the fetched Source actually belongs to that project. `LoadSourcesPaged` (the list endpoint) does correctly scope by project; only the single-item GetSource lookup is affected. `SourceResponse{*datastore.Source}` embeds the full database record with no redaction, so if the leaked Source is an AMQP/Kafka type, its `pub_sub.*.auth.password` field (a live, plaintext broker credential) is returned verbatim. ## Proof of Concept 1. As a test account, create "Victim Project" and an AMQP Source in it with a known broker password (verified against a real RabbitMQ broker, not just stored -- Convoy performs a live connectivity check before persisting an AMQP source). 2. As the same or a different authenticated caller, create a completely separate "Attacker Project". 3. Call GET /api/v1/projects/{attacker_project_id}/sources/{victim_source_id} -- i.e. a request whose URL and authorization check only ever resolve the Attacker project. 4. Verified in a Docker lab (convoy v26.6.2): the request returns 200 with the Victim project's full Source object, including pub_sub.amqp.auth.password matching the secret set in step 1 exactly. The response's own `project_id` field is the Victim project's id, never the Attacker project id used in the URL/authorization check. 5. Negative control: an otherwise-identical request for a made-up source id under the same Attacker project returns 404, confirming this is a real, ID-specific hit and not a blanket-200 endpoint. (Community Edition license-gates org_limit=1/user_limit=1, so this PoC used one account with two projects rather than two separate companies -- the vulnerable query performs no project-ownership check regardless of license tier, so a licensed multi-org deployment has the identical exposure between genuinely different tenants.) <img width="1100" height="830" alt="1_live_poc_evidence" src="https://github.com/user-attachments/assets/b2d18d3f-8e70-40ec-ad7f-7f0ac1fdebe0" /> ## Impact Any authenticated user or project-scoped API key holder who has legitimate access to at least one project on a Convoy instance can read any other project's Source configuration by ID, including plaintext third-party message-broker credentials (AMQP/Kafka/SQS/Google PubSub). In a multi-tenant deployment this is a direct cross-customer credential leak. ## Fix Add a project_id predicate to the fetchSourceByID query (and audit other single-item repository lookups reachable via a {projectID} route for the same pattern), or re-check `source.ProjectID == project.UID` in the handler before returning the record. ## Affected / Patched Affected: <= v26.6.2 (latest release at time of report). No patched version available.

CVE-2026-81505 Affected Convoy Versions

1 component(s)
Fixed Versions:
0.9.3-0.20260724092134-1cc67cd16fb1
Product / Package Ecosystem Affected Versions Fixed Version
github.com/frain-dev/convoy
Go
< 0.9.3-0.20260724092134-1cc67cd16fb1
0.9.3-0.20260724092134-1cc67cd16fb1

References

Frequently Asked Questions

What is CVE-2026-81505?
CVE-2026-81505 is a security vulnerability in Convoy involving Cross-Tenant Source IDOR Leaks Plaintext Message Broker Credentials under CWE-639: Authorization Bypass Through User-Controlled Key.
Which Convoy versions are affected?
Affected versions include releases prior to 0.9.3-0.20260724092134-1cc67cd16fb1 across affected packages: github.com/frain-dev/convoy.
What version fixes CVE-2026-81505?
Upgrading to 0.9.3-0.20260724092134-1cc67cd16fb1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/frain-dev/convoy affected?
Yes, github.com/frain-dev/convoy is affected in releases prior to 0.9.3-0.20260724092134-1cc67cd16fb1. Upgrade your dependency to 0.9.3-0.20260724092134-1cc67cd16fb1 or later.
What CWE is associated with CVE-2026-81505?
CVE-2026-81505 is classified under CWE-639: Authorization Bypass Through User-Controlled Key (The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.).
How can I check Go dependencies for CVE-2026-81505?
Run the dependency tree command: 'inspect dependencies for github.com/frain-dev/convoy'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-p5vg-v7mj-f6q4",
  "modified" : "2026-09-18T17:17:45Z",
  "published" : "2026-09-18T17:17:45Z",
  "aliases" : [ "CVE-2026-81505" ],
  "summary" : "Convoy: Cross-Tenant Source IDOR Leaks Plaintext Message Broker Credentials",
  "details" : "## Summary\nfrain-dev/convoy (all versions up to and including v26.6.2, no patch\navailable) lets any authenticated caller who is authorized on at least one\nproject read ANY OTHER project's \"Source\" record by ID via\nGET /api/v1/projects/{projectID}/sources/{sourceID} -- regardless of whether\nthat Source actually belongs to the project named in the URL. The response\nincludes the Source's full PubSub broker configuration in plaintext\n(AMQP/Kafka/SQS/Google credentials), with no redaction.\n\n## Details\n`Handler.GetSource` (api/handlers/source.go) resolves the caller's\nauthorization against the {projectID} in the URL via retrieveProject(), then\ncalls `sources.Service.FindSourceByID(ctx, project.UID, sourceID)`\n(internal/sources/impl.go). That function accepts a projectID parameter but\nnever uses it:\n\n    func (s *Service) FindSourceByID(ctx context.Context, projectID, id string) (*datastore.Source, error) {\n        row, err := s.repo.FetchSourceByID(ctx, common.StringToPgText(id))\n        ...\n    }\n\nThe underlying SQL query (internal/sources/repo/queries.sql,\n`fetchSourceByID`) has no project_id predicate at all:\n\n    SELECT ... FROM convoy.sources AS s\n    LEFT JOIN convoy.source_verifiers sv ON s.source_verifier_id = sv.id\n    WHERE s.id = $1 AND s.deleted_at IS NULL\n\nSo the {projectID} in the URL only gates \"is the caller authorized to view\n*a* project\" -- it never re-validates that the fetched Source actually\nbelongs to that project. `LoadSourcesPaged` (the list endpoint) does\ncorrectly scope by project; only the single-item GetSource lookup is\naffected. `SourceResponse{*datastore.Source}` embeds the full database\nrecord with no redaction, so if the leaked Source is an AMQP/Kafka type, its\n`pub_sub.*.auth.password` field (a live, plaintext broker credential) is\nreturned verbatim.\n\n## Proof of Concept\n1. As a test account, create \"Victim Project\" and an AMQP Source in it\n   with a known broker password (verified against a real RabbitMQ broker,\n   not just stored -- Convoy performs a live connectivity check before\n   persisting an AMQP source).\n2. As the same or a different authenticated caller, create a completely\n   separate \"Attacker Project\".\n3. Call GET /api/v1/projects/{attacker_project_id}/sources/{victim_source_id}\n   -- i.e. a request whose URL and authorization check only ever resolve\n   the Attacker project.\n4. Verified in a Docker lab (convoy v26.6.2): the request returns 200 with\n   the Victim project's full Source object, including\n   pub_sub.amqp.auth.password matching the secret set in step 1 exactly.\n   The response's own `project_id` field is the Victim project's id, never\n   the Attacker project id used in the URL/authorization check.\n5. Negative control: an otherwise-identical request for a made-up source id\n   under the same Attacker project returns 404, confirming this is a real,\n   ID-specific hit and not a blanket-200 endpoint.\n\n(Community Edition license-gates org_limit=1/user_limit=1, so this PoC used\none account with two projects rather than two separate companies -- the\nvulnerable query performs no project-ownership check regardless of license\ntier, so a licensed multi-org deployment has the identical exposure between\ngenuinely different tenants.)\n\n<img width=\"1100\" height=\"830\" alt=\"1_live_poc_evidence\" src=\"https://github.com/user-attachments/assets/b2d18d3f-8e70-40ec-ad7f-7f0ac1fdebe0\" />\n\n\n## Impact\nAny authenticated user or project-scoped API key holder who has legitimate\naccess to at least one project on a Convoy instance can read any other\nproject's Source configuration by ID, including plaintext third-party\nmessage-broker credentials (AMQP/Kafka/SQS/Google PubSub). In a\nmulti-tenant deployment this is a direct cross-customer credential leak.\n\n## Fix\nAdd a project_id predicate to the fetchSourceByID query (and audit other\nsingle-item repository lookups reachable via a {projectID} route for the\nsame pattern), or re-check `source.ProjectID == project.UID` in the handler\nbefore returning the record.\n\n## Affected / Patched\nAffected: <= v26.6.2 (latest release at time of report). No patched version\navailable.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/frain-dev/convoy"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.9.3-0.20260724092134-1cc67cd16fb1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/frain-dev/convoy/security/advisories/GHSA-p5vg-v7mj-f6q4"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/frain-dev/convoy/pull/2755"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/frain-dev/convoy/commit/1cc67cd16fb1f8890cc83a3998d3f92dceb7fd06"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/frain-dev/convoy"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/frain-dev/convoy/releases/tag/v26.6.8"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-639" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-18T17:17:45Z",
    "nvd_published_at" : null
  }
}