GHSA-P5VG-V7MJ-F6Q4
Vulnerability from github – Published: 2026-09-18 17:17 – Updated: 2026-09-18 17:17Summary
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
- 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).
- As the same or a different authenticated caller, create a completely separate "Attacker Project".
- 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.
- 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_idfield is the Victim project's id, never the Attacker project id used in the URL/authorization check. - 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.)
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/frain-dev/convoy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.3-0.20260724092134-1cc67cd16fb1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-81505"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T17:17:45Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"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\u0027s \"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\u0027s 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\u0027s\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\u0027s full Source object, including\n pub_sub.amqp.auth.password matching the secret set in step 1 exactly.\n The response\u0027s own `project_id` field is the Victim project\u0027s 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\u003cimg width=\"1100\" height=\"830\" alt=\"1_live_poc_evidence\" src=\"https://github.com/user-attachments/assets/b2d18d3f-8e70-40ec-ad7f-7f0ac1fdebe0\" /\u003e\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\u0027s 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: \u003c= v26.6.2 (latest release at time of report). No patched version\navailable.",
"id": "GHSA-p5vg-v7mj-f6q4",
"modified": "2026-09-18T17:17:45Z",
"published": "2026-09-18T17:17:45Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "Convoy: Cross-Tenant Source IDOR Leaks Plaintext Message Broker Credentials"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.