A flaw involving Reflexer Finance’s GebProxyActions contract has been exploited to steal 5.9436 ETH from four old collateral positions, raising a broader question over whether other SAFEs created through the same unintended transaction path could still be vulnerable.
Blockchain security firm SlowMist flagged the incident on Wednesday, identifying insufficient caller access control around `GebProxyActions` and the `quitSystem` flow. The exploit allowed an attacker to move collateral from positions whose ownership had inadvertently been assigned to the shared actions contract rather than to individual users’ proxy contracts.
A deeper transaction reconstruction shows that four Reflexer/GEB SAFEs — IDs 3, 5, 8 and 18 — were exploited. Together they contained 5.943599831844387377 ETH of residual collateral that the attacker was able to extract in a single transaction.
The vulnerability centers on how GebProxyActions was designed to be used.
The source code contains an unusually explicit warning that its functions are intended to operate as a library through a DSProxy and that some of them are unsafe if called directly.
Under the intended arrangement, a user calls a DSProxy that executes GebProxyActions code using `delegatecall`. That distinction is critical because, during a delegated call, Solidity’s `address(this)` refers to the individual user’s proxy.
Several functions in GebProxyActions rely on precisely that assumption.
For example, `openLockETHAndGenerateDebt` opens a SAFE and passes `address(this)` as its owner. When executed correctly through a DSProxy, the SAFE therefore belongs to the user’s proxy.
But the four positions later exploited were historically created through direct calls to the shared GebProxyActions contract. In that situation, `address(this)` was no longer an individual user’s DSProxy. It was GebProxyActions itself.
Onchain analysis found that SAFEs 3, 5, 8 and 18 consequently recorded the same GebProxyActions contract — `0x84FE…8616` — as their owner. The transactions that produced that state date back to Oct. 29 and Oct. 30, 2020.
The vulnerability then sat dormant for years.
Attacker Uses `quitSystem` to Take Residual Collateral
The attack became possible because of another feature of the GEB system: global settlement.
Reflexer’s shutdown system is intended to wind down GEB and return collateral to SAFE owners and system-coin holders. Once settlement has been triggered and a collateral type processed, positions can ultimately recover residual collateral after debt has been accounted for.
The relevant GEB deployment had entered global settlement on Jan. 25, 2021, according to the transaction analysis.
More than five years later, the attacker processed the four dormant SAFEs through settlement and then exploited the ownership state created in 2020.
`GebProxyActions.quitSystem` itself simply passes a SAFE ID and destination address into `GebSafeManager.quitSystem`. It does not verify that the external caller is the economic owner before forwarding the request.
Normally that is not necessarily a problem because the function is supposed to run inside the user’s DSProxy, where the manager sees that proxy as the caller.
Here, however, the attacker directly called the shared GebProxyActions contract.
GebSafeManager then saw GebProxyActions as `msg.sender`. Because the four affected SAFEs also listed GebProxyActions as their recorded owner, the manager’s ownership check succeeded.
The attacker supplied an address it controlled as the destination and migrated the debt-free collateral out of the SAFE handlers.
According to the transaction reconstruction, the four withdrawals comprised roughly 1.859 ETH, 1.359 ETH, 0.580 ETH and 2.147 ETH. The attacker then released the collateral through the global-settlement system, exited it as WETH, unwrapped it and moved the resulting 5.9436 ETH to an externally owned wallet.
The incident differs from a conventional smart-contract exploit where an attacker breaks an arithmetic operation or defeats an ownership modifier outright. The permissions check in GebSafeManager worked according to the ownership data it had been given.
The problem was that the ownership data itself had become unsafe years earlier.
Could Other SAFEs Still Be Vulnerable?
The initial evidence provides some reassurance, but not a complete answer.
The detailed analysis found four SAFEs owned by the shared GebProxyActions address immediately before the exploit — IDs 3, 5, 8 and 18 — and the attacker targeted all four.
That means there is currently no evidence in the published analysis of a fifth still-funded SAFE under the same examined manager carrying exactly the same ownership condition.
However, that does not establish that the vulnerability’s broader exposure is exhausted.
GebProxyActions is open-source infrastructure. Any other GEB deployment using the same contract pattern could theoretically contain positions created through direct calls rather than proper DSProxy delegation. A complete exposure assessment would therefore require checking historical SAFE-opening events and current `ownsSAFE` values across every relevant deployment, rather than looking only at the four positions already drained.
No additional losses tied to the same mechanism had been publicly identified as of Wednesday.
Analysis: The Real Bug Was an Assumption About How Users Would Call the Contract
At less than six ETH, this is not a large DeFi exploit by modern standards.
Technically, however, it is a useful example of a security problem that can survive for years because the code works perfectly when everybody uses it exactly as expected.
GebProxyActions was written around an architectural assumption: users would interact with its functions through DSProxy.
The developers knew direct interaction could be dangerous. The source code literally warns that some functions are unsafe when called directly.
But a warning in source code is not access control.
Ethereum does not know that a particular contract is supposed to be called only through `delegatecall`. If a public function exists and has no condition preventing direct execution, anybody can invoke it.
That distinction ultimately produced the ownership problem.
The most important part is also slightly different from the simplified description of the exploit circulating publicly. Calling `quitSystem` did not itself magically change a SAFE’s ownership. The exploitable state had already been created years earlier when SAFEs were opened directly through functions that expected to execute inside a proxy.
The attacker merely discovered how to use that bad ownership state.
That makes the question of additional exposure fairly concrete.
Investigators do not need to look for every user who ever touched Reflexer. They need to identify SAFEs where `ownsSAFE` points to the shared GebProxyActions contract — or equivalent action contracts in other deployments — rather than to a legitimate individual proxy or owner.
For the specific manager examined so far, the transaction analysis identified four such SAFEs, and all four were drained. That is an important limitation on the immediate story.
The potentially bigger issue is reuse.
GEB is open-source, and proxy-action patterns were common across early DeFi systems. If the same code was deployed elsewhere, or if users interacted directly with similar `open…` functions, equivalent ownership states could exist in other contracts even though this particular set of four positions is now empty.
There is also a lesson about abandoned or settled protocols.
These SAFEs were created in October 2020. Global settlement occurred in January 2021. The exploitable collateral remained available until 2026.
Old smart contracts do not disappear simply because a product is no longer actively growing.
Funds, permissions and unusual states can remain onchain indefinitely. An attacker can revisit contracts five or ten years later with better tracing tools and identify edge cases that nobody considered economically worthwhile when they were originally deployed.
That is what makes the next step more interesting than the roughly 5.94 ETH already gone.
A targeted scan should now be able to determine whether GebProxyActions is still recorded as the owner of any funded SAFE anywhere the same architecture was deployed. If the answer is no, this becomes a small exploit of four forgotten positions.
If the answer is yes, SlowMist’s alert may have revealed an attack pattern before the full amount at risk has been discovered.