Anya Skirko

Blockchain Security Researcher

[Anya Skirko @u_feature]

@HackenProof Will call non existent id. Since executeAfter will return 0 for non added one. Which will always be < block time.

[Anya Skirko @u_feature]

@andreysuperior Gross

[Anya Skirko @u_feature]

@0xw2w LLM augmented skids are ruining it for everyone. And there is no good way to detect one.

[Anya Skirko @u_feature]

@BPIV400 @cosmoslabs_io
The advisory https://t.co/JmlsmwKpmx still relies on a logging mitigation that you have failed to prove exists.
Please provide the exact log entries that unequivocally identify both the root cause of the issue and the specific malicious peer.

My standing request for a technical discussion regarding this workaround remains open and unaddressed.

Additionally, you closed a High-severity report from @ehdus829 with a bounty three days ago https://t.co/hFNdYvMAU9. This requires a public advisory and a patch so downstream projects can update their dependencies.
Please share the advisory.

[Anya Skirko @u_feature]

In Autumn of 2024 @cosmos released IBC transfers V2. They also extended 3x specials for bug reports for IBC.

The functionality was audited in Sep 2024 https://t.co/oi54m23ZPJ.

3.5 months prior to my find.

I submitted this report in the end of 2024 https://t.co/xBb7YE77ly. Transfers v2 functionality introduced an ability for a malicious actor to make a legitimate transfer v2 channel non-upgradable.

The exploit was utilizing the absence (by design) of any authentication for chains and the functionality that prevents packets replay. So potential fix could introduce a critical vulnerability.

The issue for disabling v2 transfers appeared on Feb 10 2025 https://t.co/FdZNj5kceg. Around 6 weeks after my report.

In the end of May, 2025, 5 months after I submitted the report. And exactly when they finished moving packet forwarding middleware from ibc-apps to ibc-go https://t.co/Q85F1sWpl8. A code that functionally replaces transfers v2.

They closed my report without assigning any severity and "rewarded" with low bounty without even applying a 3x multiplier.

With the following justification: "Transfer v2 was retracted eventually and channel upgradeability removed, which resolves this issue. We classify this issue as a low severity issue (at the time of writing)" @BPIV400

[Anya Skirko @u_feature]

@Aditya_181105 Depends on the use case. Java won’t leave corporate enterprise for a long time. Node.js is a mistake.

[Anya Skirko @u_feature]

@Tech_girlll Any creative job. Which requires novelty. Or generates chaos. In software development it’s exploratory and freestyle adversarial testing.

[Anya Skirko @u_feature]

I’m not sure if H1 is one of those who doesn’t want you to use AI. Their CEO went beyond full mode on AI. Including adding AI report generator. While other platforms attempted to fight the slop. And based on the CEOs recent posts on LinkedIn it doesn’t seem like the issue is acknowledged.

[Anya Skirko @u_feature]

@HackenProof Bug 2 is that transfer happens to the msg.sender instead of the account. The same sender can get proofs from valid trie and send as many as not claimed yet to get themselves the token. And the first one is as everyone said no access control/crypto verification to updateRoot.

[Anya Skirko @u_feature]

@ehdus829 you got the advisory I asked you here https://t.co/l2dpbT6mjc ? Due to a miracles coincidence your "High" severity report turned out legitimate while the one that you had proofs was legitimate - no. What a turn of events!

There is no way High severity vulnerability report was closed without a fix. And as I said here https://t.co/l2dpbT6mjc no fix was observed in main components covered by BB. Did they leave it unpatched? If no, please, share the advisory. If vendor hasn't issued the advisory, please, request one as they need to issue one for downstream projects.

[Anya Skirko @u_feature]

1. You reported 2 bugs to Cosmos. One Medium, and one High. You went with the escalation of Medium (not High) to the end. You disclosed it. If you were that confident about the High one you’d have escalated it instead.

2. Then after the escalation of the Medium, the vendor allegedly recognized the mistake on the other report and rewarded you with a bounty. While retaining the position with regards to the Medium one which already went public together with discrediting facts about their process which you shared.

3. There were no releases in cosmos-sdk, cometbft, evm, ibc-go, ibc-solidity-eureka, wasmd between the moment when the vendor stated they’ll review your reports and the moment your High report was closed with the bounty. Not clear where the fix went and where the advisory is. Please, share if the advisory was issued. It’s unlikely that the report was closed before the fix got implemented. And the vendor is required to publish the advisory since downstream projects need to update their dependencies.

4. The same day you got paid you dropped a discrediting post and edited the GitHub issue by removing all the facts that were pointing out at the vendor's irresponsible behavior. After that you interfered multiple times with my attempts to establish technical truth by continuously claiming “but the vendor’s assessment” and downplaying the impact. Which directly cancels your claim that “we share the same position on technical truth.”

The vendor’s assessment remained the same. Nothing changed there. And as per your initial statement you cared about the community. This part has changed as you dropped discrediting evidence as soon as you received the payment.

You surrendered your legitimate bug and you surrendered your credibility.

You can’t make a way out of this via LLM-generated text that contradicts reality. It only proves my points.

[Anya Skirko @u_feature]

@shibu0x aw, that's painful 🫂

[Anya Skirko @u_feature]

@BPIV400 @cosmoslabs_io
The advisory https://t.co/JmlsmwKpmx still relies on a logging mitigation that you have failed to prove exists.
Please provide the exact log entries that unequivocally identify both the root cause of the issue and the specific malicious peer.

My standing request for a technical discussion regarding this workaround remains open and unaddressed.

Additionally, you closed a High-severity report from @ehdus829 with a bounty three days ago https://t.co/hFNdYvMAU9. This requires a public advisory and a patch so downstream projects can update their dependencies.
Please share the advisory.

[Anya Skirko @u_feature]

@ehdus829 You are not displaying any integrity or actual care for the "community" by deleting your original post after cashing out. Your piggy-backed submission and lack of understanding gave the triage team the exact excuse they needed to make a deterministic failure appear to be a "non-issue."

The vulnerability remains active. Chains are trying to privately patch it and failing because the core architectural flaw was swept under the rug instead of being fixed in stealth. https://t.co/C9ToazhEev

@cosmoslabs_io has now exposed this problem to every malicious actor who has an hour of time to spin up the exploit. But downstream projects still rely on the good faith and academic excellence that used to exist behind the brand.

Once again, this attack has a window of opportunity during blocksync and can prevent nodes from participating in consensus.

My multiple requests for technical discussion remain unanswered. Which is an answer on its own.

If the security team and @BPIV400 insist this is easily mitigated, they must publish the exact log entries required to identify the malicious actor, so downstream projects can implement the alleged workaround.

[Anya Skirko @u_feature]

1. You reported 2 bugs to Cosmos. One Medium, and one High. You went with the escalation of Medium (not High) to the end. You disclosed it. If you were that confident about the High one you’d have escalated it instead.

2. Then after the escalation of the Medium, the vendor allegedly recognized the mistake on the other report and rewarded you with a bounty. While retaining the position with regards to the Medium one which already went public together with discrediting facts about their process which you shared.

3. There were no releases in cosmos-sdk, cometbft, evm, ibc-go, ibc-solidity-eureka, wasmd between the moment when the vendor stated they’ll review your reports and the moment your High report was closed with the bounty. Not clear where the fix went and where the advisory is. Please, share if the advisory was issued. It’s unlikely that the report was closed before the fix got implemented. And the vendor is required to publish the advisory since downstream projects need to update their dependencies.

4. The same day you got paid you dropped a discrediting post and edited the GitHub issue by removing all the facts that were pointing out at the vendor's irresponsible behavior. After that you interfered multiple times with my attempts to establish technical truth by continuously claiming “but the vendor’s assessment” and downplaying the impact. Which directly cancels your claim that “we share the same position on technical truth.”

The vendor’s assessment remained the same. Nothing changed there. And as per your initial statement you cared about the community. This part has changed as you dropped discrediting evidence as soon as you received the payment.

You surrendered your legitimate bug and you surrendered your credibility.

You can’t make a way out of this via LLM-generated text that contradicts reality. It only proves my points.

[Anya Skirko @u_feature]

In order for this to happen you have to have formal mathematically precise spec.

Which describe not just each and every functional but also non functional aspect.

"It is also the only evolving formally-verified code base of the order of 10 000 lines of code and we report on maintaining it for almost a decade together with its now 480 000 lines of Isabelle proofs and specifications."

https://t.co/ZqB32GIZrS Can you give more details on who/what will be writing such specs?

[Anya Skirko @u_feature]

@ehdus829 @cosmos Let's keep it here so everyone could see that @ehdus829 decision to drop the post wasn't influenced by money.

[Anya Skirko @u_feature]

@ehdus829 @cosmos There is a PR waiting for your review https://t.co/sUXn2bRtgR

[Anya Skirko @u_feature]

@0xZulkifilu Plus they don't do well with cross-module and business logic stuff. I do find LLM to be helpful as a working horse: "go investigate this", "go write that", "verify if i understand this right". But still the process is mostly manual. So far at least.

[Anya Skirko @u_feature]

In Autumn of 2024 @cosmos released IBC transfers V2. They also extended 3x specials for bug reports for IBC.

The functionality was audited in Sep 2024 https://t.co/oi54m23ZPJ.

3.5 months prior to my find.

I submitted this report in the end of 2024 https://t.co/xBb7YE77ly. Transfers v2 functionality introduced an ability for a malicious actor to make a legitimate transfer v2 channel non-upgradable.

The exploit was utilizing the absence (by design) of any authentication for chains and the functionality that prevents packets replay. So potential fix could introduce a critical vulnerability.

The issue for disabling v2 transfers appeared on Feb 10 2025 https://t.co/FdZNj5kceg. Around 6 weeks after my report.

In the end of May, 2025, 5 months after I submitted the report. And exactly when they finished moving packet forwarding middleware from ibc-apps to ibc-go https://t.co/Q85F1sWpl8. A code that functionally replaces transfers v2.

They closed my report without assigning any severity and "rewarded" with low bounty without even applying a 3x multiplier.

With the following justification: "Transfer v2 was retracted eventually and channel upgradeability removed, which resolves this issue. We classify this issue as a low severity issue (at the time of writing)" @BPIV400