Summary
Aloha has a per-object execute permission model, but the live A2A proxy route calls getServer(req, res, A2AServer) without enabling that check. The replay shows a caller with only coarse proxy access reaches a private A2A server and receives HTTP 200. The same request is rejected with 403 when the existing getServer(..., true) execute gate is enabled.
Affected Target Verified
- Repository:
https://github.com/ec-jrc/aloha
- Component:
/api/a2a/{serverPath} proxy route
- Affected commit verified:
a1b90ef1473600630b7511fda9c4ae31b2b1b1e0
- Vulnerability type: Authorization parity bug on A2A proxy route
Preconditions
- A private A2A server is registered behind Aloha.
- A caller has coarse proxy API access but lacks execute permission for the target server.
- The caller sends through
/api/a2a/{serverPath}.
Steps To Reproduce
From the attachment directory:
The script clones the target repository, checks out the verified commit, prepares a local test environment, and runs the bundled PoC. It does not contact attacker-controlled services; the setup only downloads the public repository and normal build dependencies.
To run against an existing checkout:
ALOHA_TARGET_DIR=/path/to/checkout bash reproduce.sh
The wrapper accepts ALOHA_TARGET_DIR for an existing checkout. It also accepts the target commit override documented in attachments/reproduce.sh.
Technical Details
The A2A proxy route uses the server lookup helper without the checkAuth=true argument that enforces object-level execute permission.
Expected Behavior
The A2A proxy route should enforce the same per-object execute permission check
as other execute-capable proxy paths before forwarding a request to a registered
private server.
Actual Behavior
- Live route returns 200 with only
ProxyApiAccess.
- Comparison path with existing execute gate returns 403 for the same target.
Impact
A caller authorized only for coarse proxy access can reach a registered private
A2A server that the existing execute permission model would otherwise deny.
The reproduced comparison path shows the same target is rejected once the
existing per-object execute gate is enabled.
This collapses the distinction between "may use the proxy endpoint" and "may
execute this specific server." If private A2A servers are connected to internal
agents, tools, datasets, or tenant-specific workflows, a caller with proxy
access can send A2A requests to those servers and receive their responses even
without execute permission for the object.
The issue is specific to authorization parity on the A2A proxy route. It does
not require guessing task ids or relying on A2A task-store behavior; the route
forwards to the private server before applying the same object-level check used
by the stronger execute path.
Suggested Fix
Use the same object-level execute permission check on A2A proxy routes as on other execute-capable proxy paths. Add regression coverage for private A2A servers.
Attachments
attachments.zip
Summary
Aloha has a per-object execute permission model, but the live A2A proxy route calls
getServer(req, res, A2AServer)without enabling that check. The replay shows a caller with only coarse proxy access reaches a private A2A server and receives HTTP 200. The same request is rejected with 403 when the existinggetServer(..., true)execute gate is enabled.Affected Target Verified
https://github.com/ec-jrc/aloha/api/a2a/{serverPath}proxy routea1b90ef1473600630b7511fda9c4ae31b2b1b1e0Preconditions
/api/a2a/{serverPath}.Steps To Reproduce
From the attachment directory:
The script clones the target repository, checks out the verified commit, prepares a local test environment, and runs the bundled PoC. It does not contact attacker-controlled services; the setup only downloads the public repository and normal build dependencies.
To run against an existing checkout:
The wrapper accepts
ALOHA_TARGET_DIRfor an existing checkout. It also accepts the target commit override documented inattachments/reproduce.sh.Technical Details
The A2A proxy route uses the server lookup helper without the
checkAuth=trueargument that enforces object-level execute permission.Expected Behavior
The A2A proxy route should enforce the same per-object execute permission check
as other execute-capable proxy paths before forwarding a request to a registered
private server.
Actual Behavior
ProxyApiAccess.Impact
A caller authorized only for coarse proxy access can reach a registered private
A2A server that the existing execute permission model would otherwise deny.
The reproduced comparison path shows the same target is rejected once the
existing per-object execute gate is enabled.
This collapses the distinction between "may use the proxy endpoint" and "may
execute this specific server." If private A2A servers are connected to internal
agents, tools, datasets, or tenant-specific workflows, a caller with proxy
access can send A2A requests to those servers and receive their responses even
without execute permission for the object.
The issue is specific to authorization parity on the A2A proxy route. It does
not require guessing task ids or relying on A2A task-store behavior; the route
forwards to the private server before applying the same object-level check used
by the stronger execute path.
Suggested Fix
Use the same object-level execute permission check on A2A proxy routes as on other execute-capable proxy paths. Add regression coverage for private A2A servers.
Attachments
attachments.zip