EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/dapr/daprReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A vulnerability has been found in Dapr that causes a leak of the application token of the invoker app to the invoked app when using Dapr as a gRPC proxy for remote service invocation. This issue arises because Dapr sends the app token of the invoker app instead of the app token of the invoked app.
Users who leverage Dapr for gRPC proxy service invocation and are using the app API token feature are encouraged to upgrade Dapr to version 1.13.3.
Impact
This vulnerability impacts Dapr users who use Dapr as a gRPC proxy for remote service invocation as well as the Dapr App API token functionality. An attacker could exploit this vulnerability to gain access to the app token of the invoker app, potentially compromising security and authentication mechanisms.
Patches
The issue has been fixed in Dapr version 1.13.3.
Details
Dapr uses two types of tokens for authentication:
APP_API_TOKEN: Used by Dapr to authenticate to the app.DAPR_API_TOKEN: Used by the app to authenticate to Dapr.
Dapr uses the dapr-api-token metadata in gRPC calls (or header, for HTTP calls) for authentication.
- In communication from dapr to the app, the
dapr-api-tokenmetadata field will carry theAPP_API_TOKEN. - In communication from the app to daprd, the
dapr-api-tokenmetadata field will carry theDAPR_API_TOKEN.
Before version 1.13.0, the APP_API_TOKEN was not being sent to the invoked app for authentication, as reported in this issue. Instead, Dapr was incorrectly using the same DAPR_API_TOKEN that the invoker app had passed to Dapr. This was addressed in PR #7404, but the fix only worked for self-invocation scenarios.
When Dapr needed to communicate with another instance, it would mistakenly include the APP_API_TOKEN of the invoker app in the request. This behavior is incorrect, app tokens should never be included in requests between Dapr sidecars. This vulnerability allows the receiving app to see the app token of the invoker app, leading to potential misuse and security breaches.
The vulnerability is addressed by ensuring that Dapr uses the correct app token (of the invoked app) during gRPC proxy service invocation.
References
- https://docs.dapr.io/operations/security/app-api-token/
- https://github.com/dapr/dapr/issues/7344
- https://github.com/dapr/dapr/pull/7404
Credits
Thanks to Benjamin Delay for reporting this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/dapr/dapr | ≥ 1.13.0&&< 1.13.3 | 1.13.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/dapr/dapr. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/dapr/dapr to 1.13.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-284c-x8m7-9w5h is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-284c-x8m7-9w5h is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-284c-x8m7-9w5h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-284c-x8m7-9w5h in your dependencies?
O3 detects GHSA-284c-x8m7-9w5h across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.