<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>MaxKey (4.1.12) - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/maxkey-4.1.12/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 30 Jul 2026 15:33:28 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/maxkey-4.1.12/feed.xml" rel="self" type="application/rss+xml"/><item><title>Insufficient Redirect URI Validation in MaxKey</title><link>https://feed.craftedsignal.io/briefs/2026-07-maxkey-oauth-vuln/</link><pubDate>Thu, 30 Jul 2026 15:33:28 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-maxkey-oauth-vuln/</guid><description>MaxKey versions through 4.1.12 are vulnerable to OAuth 2.0 authorization code hijacking due to improper host boundary checks in the DefaultRedirectResolver component.</description><content:encoded><![CDATA[<p>MaxKey versions through 4.1.12 contain a security vulnerability in the DefaultRedirectResolver.hostMatches() method. The issue stems from insufficient validation of redirect URIs during the OAuth 2.0 authorization process. Specifically, the application fails to enforce proper dot-boundary anchoring when comparing the provided redirect_uri against registered URIs. This flaw allows an attacker to supply a crafted redirect_uri that shares a hostname suffix with a legitimate registered URI, effectively bypassing validation checks. By utilizing social engineering to entice a victim to initiate an authorization request via a malicious link, an attacker can cause the authorization server to send the authorization code to an attacker-controlled endpoint. The attacker then exchanges this code for an access token, resulting in unauthorized access to the victim's account and identity. Organizations using MaxKey 4.1.12 or earlier should apply the fix provided in commit ddbb72f.</p>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows remote, unauthenticated attackers to hijack OAuth 2.0 authorization codes. This leads to the unauthorized acquisition of access tokens, enabling the attacker to impersonate the victim, access protected resources, and potentially escalate privileges within the environment. This affects all deployments of MaxKey relying on the standard OAuth 2.0 authorization flow.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade MaxKey instances to a version containing the fix for CVE-2026-67345 (commit ddbb72f).</li>
<li>Review application logs for unusual redirect_uri patterns in OAuth authorization requests, specifically checking for domains that match the suffix of authorized clients without proper sub-domain or TLD isolation.</li>
<li>Audit all registered OAuth 2.0 client redirect URIs in MaxKey to ensure they are fully qualified and follow strict matching standards.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>oauth</category><category>identity-management</category><category>cve-2026-67345</category></item></channel></rss>