Details
## 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.
