On November 22-23, 2025, Port3 suffered a major exploit. The attacker minted approximately 1 billion PORT3 tokens via a vulnerability, sold a portion of them (~162.75 million) for ~199.56 BNB (~US$166,000) and burned the remainder (~837.25 million). As a result, PORT3’s price fell over ~80% within a very short period.
Port3’s team confirmed identification of the full scope of the incident and announced they would migrate the token to a new contract and carry out remediation (including burning tokens, coordinating with exchanges).
Technical Root-Cause
Vulnerability
- The exploit stemmed from a boundary-condition validation vulnerability in the cross-chain token solution named CATERC20 (provided by NEXA Network) which Port3 had adopted.
- Specifically: when token ownership is renounced (i.e., the owner field is set to zero address), the function returned value “0”, which by coincidence satisfied the “owner verification” condition in the code. In plain terms: the contract logic allowed “owner==0” to pass a check meant only for valid owner addresses.
- Because Port3 had renounced contract ownership (in the name of decentralisation), they inadvertently triggered the condition: their token contract was left in a state where the “owner” was effectively zero address, and the flawed verification then allowed unauthorized operations.
- The attacker exploited this by performing a “RegisterChains” operation (registering their own address as an authorized chain) and then executed a “BridgeIn” operation (cross-chain mint) on the BNB Chain, minting ~1 billion tokens.
Contract/Bridge context
- The vulnerability arises in cross-chain token mechanics: the token is CATERC20 (which is intended to support multi-chain bridging). Because of the flawed owner check, the attacker could register chain parameters and mint tokens unilaterally.
- Port3’s contract logic had relinquished ownership (so there was no “owner” control) which in normal circumstances strengthens decentralization, but given the flawed verification logic this created a permanent back-door.
Timeline & Exploit Sequence
- Prior to the exploit: Port3 had adopted the CATERC20 solution, renounced ownership, and was running multi-chain bridging.
- Time of exploit: Official time is around UTC 20:56:24 on 22 or 23 November when attacker address 0xb13A503dA5f368E48577c87b5d5AEC73d08f812E (and similar) executed RegisterChains on the contract.
- Immediately following, the attacker minted ~1 billion PORT3 tokens on BNB Chain via BridgeIn.
- The attacker sold approx. 162.75 million tokens for ~199.56 BNB (~US$166k)
- The remaining ~837.25 million tokens were burned by the attacker (or at least sent to a burn address)
- Market reaction: Token price dropped ~80% (>-76% to -82%) within a short timeframe.
- Port3 took emergency actions: removed on-chain liquidity, pulled the liquidity pool, communicated with exchanges to suspend deposits/withdrawals.
- The team then announced a token migration: 1:1 swap to a new contract (on BNB Chain only), snapshot taken, and approx. 162.75 million tokens will be burned to offset excess supply.
Impact & Damage Metrics
- Financial: The attacker realised ~US$166,000 from the dump (~162.75 m tokens → 199.56 BNB)
- Market cap/price: The token price dropped from approx. US$0.037 to a low of ~US$0.0066 (~82% drop) and later rebounded to ~US$0.0086
- Circulating supply distortion: ~1 billion tokens minted, but only ~162 m sold; the rest burned. This temporary inflation risked destroying tokenomics confidence
- Exchanges: Some centralised exchanges suspended PORT3 deposits; spot and derivative markets impacted
- Sentiment & trust: Investors and ecosystem participants saw this as another cross-chain/bridge vulnerability incident, undermining confidence in multi-chain token architectures.
Key Lessons / Security Insights
From this incident, several broader security insights emerge:
Renouncing ownership is not a panacea
While renouncing contract ownership may sound good for decentralisation, if the contract logic uses “owner==0” as a valid bypass or verification mechanism, this opens a latent risk. In other words the risk moved from “owner has privileges” to “zero address becomes implicitly privileged”.
Cross-chain token/bridge logic is high-risk
The exploit leveraged the cross-chain registration (RegisterChains) + mint (BridgeIn) functionality. Any cross-chain token standard must be audited with extreme caution for registration/authorization logic, especially with multi-chain complexity.
Boundary-condition & edge-case checks matter
Here the bug was a boundary-condition: “owner == 0” matched the verification condition erroneously. Such edge cases often evade typical audits. It emphasises the need for fuzzing, formal verification and scenario testing of owner/authorization logic.
Audit gap
The vulnerability was not found during the CATERC20 audit (per reports). This indicates that relying on a standard audit without project-specific context may produce false sense of security. Audit scopes must include custom configurations (renouncing ownership, multi-chain roles, bridging contracts).
Rapid incident response matters
Port3’s team removed liquidity, communicated with exchanges, and announced remediation. This containment reduced further damage (only ~US$166k realised). Rapid response is a key mitigation vector in DeFi incidents.
Assets are not fully shielded just because funds are not drained
While the attacker didn’t directly extract large value beyond the dump, the damage to tokenomics, market confidence, and potential legal/regulatory fallout is meaningful. For projects, security risk includes reputational and systemic risk beyond direct losses.
Token migration as remediation has secondary risks
Changing contracts, doing snapshot migrations, burning large quantities of tokens all create operational complexity and potential for additional risk (e.g., phishing, faulty migration, liquidity issues).
Recommendations & Next Steps (for Projects / Auditors)
Given this case, for your Web3 security toolset and audit framework you may incorporate:
Ownership logic review: Always verify what happens when ownership is renounced (owner set to zero-address). Confirm that the contract does not treat zero-address as implicitly privileged.
Bridge/token registration logic audit: Inspect functions like RegisterChains, BridgeIn/BridgeOut, mint/burn methods, and ensure permission checks cannot be bypassed via cross-chain parameters.
Authorization model mapping: Build a complete permission model map: owner, admins, registrars, minters, cross-chain roles. Then test edge cases (e.g., owner==0, address==0, multiple chains, reuse of roles).
Fuzzing & flow testing for cross-chain paths: For multi-chain tokens, simulate chain registrations, transfers, bridging events, handling of tokens across chains, and ensure invariant supply is maintained.
Audit hand-off risk: When using third-party token standards (e.g., CATERC20), treat them as dependencies and include them in the audit scope (or at least perform integration audit). A chain of trust exists: your integration + dependency = risk.
Incident readiness: Have a checklist for rapid response: liquidity removal, exchange coordination, snapshot procedures, token-migration pathways, communication to community, burn/offset plan. The difference between contained damage and catastrophic loss often lies in preparedness.
Tokenomics & trust modelling: After a hack, token migration, burns, etc., projects must transparently communicate what changed in supply, circulating/locked tokens, contract address, minting privileges, bridging paths. Lack of transparency fosters exit risk.
TLDR
The Port3 incident is a textbook example of how a cross-chain token contract with insufficient boundary checks and ownership renouncement can lead to a minting exploit, despite no direct “draining” of funds. The attacker’s rapid mint-dump-burn sequence caused severe token collapse and reputational harm.
For stakeholders in the security space the case underscores that decentralisation (renouncing ownership) is not a substitute for explicit permission logic, and that bridging/registration mechanisms carry disproportionate risk.
Our Services
https://credshields.com/smart-contract-audits
https://credshields.com/dapp-protocol-security
https://credshields.com/blockchain-security