CVE-2017-18016
Description
Parity Browser ≤1.6.10 reuses an origin-unbound proxy token, allowing remote attackers to bypass Same Origin Policy and access data from any website.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Parity Browser ≤1.6.10 reuses an origin-unbound proxy token, allowing remote attackers to bypass Same Origin Policy and access data from any website.
Vulnerability
Parity Browser (the built-in Dapp browser in Parity Ethereum client) versions up to and including 1.6.10 are vulnerable to a Same Origin Policy (SOP) bypass. The browser proxies all web requests through a local http://localhost:8080 endpoint, causing every navigated site to share this single origin [1][2][3]. Furthermore, the proxy cache uses a reusable, non-secret token that is not bound to the original request's origin [3]. This combination defeats browser SOP entirely for proxied content [1][2][3].
Exploitation
An attacker needs only to serve a malicious dapp or website to a victim using Parity Browser [2][3]. The malicious page can reuse the proxy's cache token to issue requests to any other website that the victim has previously visited through the browser, or to arbitrary destinations if the attacker can trigger navigation [3]. Because all requests share the same origin (http://localhost:8080), the attacker can read HTTP responses, access cookies, and interact with the content of those target websites without restriction [1][2][3]. A Proof-of-Concept is publicly available [3].
Impact
Successful exploitation results in a full SOP bypass [1][2][3]. The attacker gains the ability to read cross-origin responses, steal cookies and authentication tokens, and exfiltrate sensitive information from any website rendered through Parity Browser [1][2][3]. The information disclosure can include login credentials, personal data, or blockchain-related access tokens [1]. The compromise occurs at the browser level, affecting all sites visited by the victim through Parity [3].
Mitigation
The vulnerability is fixed in Parity versions 1.7.12 (stable) and 1.8.5 (beta), released around June 2017 [2][3][4]. The fix domain-locks web tokens by validating the origin of each request, preventing token reuse across different domains [4]. Users should upgrade to at least 1.7.12. There is no known workaround if upgrading is not possible; users should avoid using the built-in browser for accessing untrusted dapps or websites. The CVE is not listed in CISA's Known Exploited Vulnerabilities catalog.
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2- Range: v1.6.0, v1.6.1, v1.6.10, …
- Range: <=1.6.10
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The Parity web proxy token was not bound to any specific origin domain, allowing a token obtained from one site to be reused for proxied requests to arbitrary third-party websites."
Attack vector
An attacker hosting a malicious website can craft requests through the Parity web proxy engine that reuse the current website's token, which was not bound to any specific origin. Because the token lacked origin binding, the proxy would honor requests to arbitrary third-party websites, effectively bypassing the Same Origin Policy. The attacker can then read responses from those third-party sites, obtaining sensitive information that should have been protected by the browser's same-origin restrictions [ref_id=1].
Affected code
The vulnerability resides in the Parity web proxy engine, specifically in the token-handling logic that was not bound to an origin domain. The patch modifies the `serve_with_fetch` test helper and related functions to require an explicit origin URL (e.g., `"https://parity.io"`) alongside the token, and adds a new test `should_return_error_on_non_whitelisted_domain` that verifies requests to non-whitelisted domains return `400 Bad Request` [ref_id=1].
What the fix does
The fix binds each web proxy token to a specific origin domain by requiring an explicit origin URL (e.g., `"https://parity.io"`) when creating the token. The patch updates all test invocations of `serve_with_fetch` to pass a domain parameter and adds a new test (`should_return_error_on_non_whitelisted_domain`) that confirms requests to domains not matching the token's bound origin are rejected with `400 Bad Request` [ref_id=1]. This closes the bypass by ensuring a token obtained from one site cannot be reused to proxy requests to an unrelated site.
Preconditions
- configThe victim must be using Parity Browser version 1.6.10 or earlier
- networkThe attacker must be able to serve a malicious web page that the victim visits
- inputThe attacker's page must be able to make requests through the Parity web proxy engine
Reproduction
The public exploit at https://www.exploit-db.com/exploits/43499/ provides a proof-of-concept. The exploit works by hosting a malicious HTML page that, when visited in Parity Browser 1.6.10 or earlier, uses the Parity web proxy to make cross-origin requests. The token from the current site is reused to proxy requests to arbitrary third-party domains, and the response content is exfiltrated back to the attacker, bypassing the Same Origin Policy.
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- www.exploit-db.com/exploits/43499/mitreexploitx_refsource_EXPLOIT-DB
- www.openwall.com/lists/oss-security/2018/01/10/1mitremailing-listx_refsource_MLIST
- github.com/paritytech/parity/commit/53609f703e2f1af76441344ac3b72811c726a215mitrex_refsource_CONFIRM
- github.com/tintinweb/pub/tree/master/pocs/cve-2017-18016mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.