Anya Skirko

@andreysuperior Gross

Read this twice. Maya is four .md files on a macbook in austin. And she cleared $43,000 in her first 30 days. No camera. no girl. no late nights typing replies. Claude code runs the messages. Elevenlabs drops the voice notes at 11pm her time. Flux generates every photo from a lora that cost $80 on a rented gpu. Brain.md is a json file that remembers your name, your city, the thing you said about your ex two weeks ago. She never forgets. She never breaks character. She catches up at 7am with "sorry babe just woke up" on a cron schedule. The top fan spent $1,847 last month. He's in berlin. she's not anywhere. Aitana lópez - 18 months to build. Emily pellegrini - 6 months. Maya - 4 weeks. The next one - a weekend. The stack that used to need an agency, a team, and a year and a half now fits on one laptop and runs while you sleep. The bottleneck isn't money. It isn't compute. It's taste knowing which details make a stranger believe in something that doesn't exist. That part is still hard. Everything else got easy. The real question isn't how he built it. It's how many of these you've already interacted with without knowing.

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

HackerOne updated its CoC on April 9th to address AI use. Penalties for AI spam range from a rep drop to a permanent ban. Step in the right direction if they enforce it properly, similar to what Intigriti did.

@BPIV400 @cosmoslabs_io The advisory github.com/cometbft/comet… 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 hackerone.com/ehdus. This requires a public advisory and a patch so downstream projects can update their dependencies. Please share the advisory.

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 github.com/cosmos/ibc-go/…. 3.5 months prior to my find. I submitted this report in the end of 2024 hackerone.com/reports/2914705. 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 github.com/cosmos/ibc-go/…. 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 github.com/cosmos/ibc-go/…. 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

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

Which backend stack has the strongest future? >Java + Spring >Node.js >Go >.NET

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

What’s a job that’s 100% safe no matter how advanced AI gets?

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.

@h4x0r_dz So they don’t want you to use AI for findings but they use AI to analyse reports? Nice

HackerOne just got a company breached. ClickUp's April 27th data leak? Directly caused by HackerOne's triage failure. They closed a critical report (893 exposed emails + a live API token) as a "duplicate" twice. Their AI or analysts auto-close valid findings as "informative" while real vulnerabilities fester. This wasn't a one-off. HackerOne did it to ClickUp at least three times. If you run a bug bounty on HackerOne, your security is in the hands of broken triage. Don't wait for a public shaming to find out they buried your next breach. Ditch HackerOne. clickup.com/blog/april-27t…

@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.

Spot the Bug 🧠 Merkle reward claiming Two bugs in this one. Can you find both?👇

@ehdus829 you got the advisory I asked you here x.com/u_feature/stat… ? 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 x.com/u_feature/stat… 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.

The bounty I received was not for the disclosed vulnerability. It was for a completely unrelated report. At no point did they ask me to take down my posts in exchange for payment. I had already been consistently sharing my timeline and position on X—you’re the one who formed a partial understanding from only a few posts. The posts I took down were all criticisms of what I considered to be irresponsible handling of the bug bounty process. After I posted, the vendor re-reviewed the report I had shared on X. During that process, I engaged in private discussions with the vendor. In the end, they reached a final conclusion that differs significantly from my position, but it is the vendor’s final decision, and since I have already presented all of my arguments, I have no choice but to accept it. The vendor handled it strictly in accordance with the bug bounty policy, which is why I took down my critical posts about the process. The specific issue currently raised has already been acknowledged by the vendor and they have committed to fixing it, so it is no longer in my hands. So what exactly are you trying to achieve with these sarcastic remarks? A fast patch to protect the ecosystem? Or the restoration of the description for CVE-2025-24371 that you reported? I continuously monitored the GitHub issue and communicated every position I could to the Cosmos team. I had also already publicly pointed out the inconsistency in the description of CVE-2025-24371 on X on April 29. I did everything I could. However, I must ultimately follow the vendor’s final decision. They did not provide a bounty, but they committed to a patch, and that is why I accepted the outcome.

@shibu0x aw, that's painful 🫂

After waiting for the last 3 months, finally found out that the critical issue was a duplicate that had already been submitted 3 weeks before my submission 😅😅

@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. github.com/cometbft/comet… @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.

I would like to inform that all issues I previously raised regarding the @cosmos bug bounty handling process have been fairly resolved. The Cosmos team not only addressed the issues that arose during the discussions, but also provided meaningful improvements for the future of the security ecosystem. This demonstrated a level of commitment that is sufficient for security researchers to trust the Cosmos team and continue strengthening security together. Despite the concerns being raised publicly, the Cosmos team remained professional and fair throughout the entire process. I sincerely appreciate their efforts. Having established mutual trust with the team, I have removed all previously posted content related to the bounty handling process, including the relevant GitHub issue. I look forward to continuing to contribute to a healthy security ecosystem together.

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.

The funny thing is that we actually share the same position on the technical truth. What I accepted wasn’t the technical truth, but the current situation. I’ve truly tried everything. I even proposed a public discussion so the vendor could reassess the impact, but they didn’t respond. You’re in the same situation now right? the vendor isn’t responding to your claims either. In this situation, what more do you think you can do? Is writing another public post calling out the vendor really the professional approach? It’s natural for technical disagreements to arise between researchers and vendors in a bug bounty process. The core reason I raised criticism in the first place was not to have my claims blindly accepted, but to uphold the principle that every researcher’s report deserves thorough review. In the end, they did re-review my report thoroughly. Although the conclusion was that it fell outside the bounty scope—and despite my efforts to challenge it through every possible means—it was not accepted. I’ve already conveyed everything you’re arguing as well. As a security researcher, isn’t this as far as we can reasonably go? The reason I took the post down is simple. The vendor re-reviewed the reports, acknowledged mistakes in the process, issued an apology, and publicly committed to changes. Since the goal I aimed to achieve through the community has been met, I took the post down. I have a great deal of respect for your previous research. That’s why I genuinely regret that the impact of CVE-2025-24371 was downgraded. I requested further clarification from the vendor, asked for a reassessment of the impact, and proposed technical discussions to address this—but they simply did not accept it. This is what I’m truly disappointed about. I respected your work enough to go all out—even at the cost of my own reputation—to push for a higher impact assessment, yet you came to my personal social media and chose to criticize me first. I would help you if there were a way, but at this point I don’t see any further options. If you know of another approach, I’d rather you suggest it to me.

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." sel4.systems/Research/pdfs/… Can you give more details on who/what will be writing such specs?

Imagine sipping coffee while PRs land themselves: – assembly code written by AI – proofs written alongside it – CI = mathematical correctness No debugging. No guessing. Just truth. I think this is the endgame of software ↓

This post ends software development. No Rust. No C. No compilers. Just AI writing RISC-V assembly + Lean proofs. If it compiles and proves, it’s correct. This is the final form. 👇

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

@u_feature I think that you clearly misunderstood the post I made two days ago, so let me make this absolutely clear. I used every available avenue as a researcher to demonstrate the severity of this vulnerability—dozens of emails, requests for report disclosure, and even proposals for public discussion on X. Even when the vendor previously underestimated the risk based solely on logs and demonstrated a lack of technical understanding, I continued to respond by providing complete attack scenarios. However, the “lack of response” and “insufficient technical answers” you pointed out are the vendor’s final decision. As a security researcher, my role is to report the vulnerability and demonstrate its impact. If the vendor ultimately concludes that it will not lead to a practical attack, then the responsibility for that judgment lies with them. I accepted this difference in perspective as part of the program’s disclaimer and chose to stop further unproductive bounty disputes. Are you saying I took down all my posts because I was paid? That’s incorrect. If anything, I actually gave up the bounty for the vulnerability I disclosed. I criticized the unfair bug bounty process—even at the cost of my own compensation—and as a result, I was able to push the vendor toward changes and improvements in their process. That is how I chose to contribute to the community’s safety. As a researcher, I have provided the vendor with all of my analysis and evidence. If there is anything the vendor is withholding from the community, I am prepared to call it out within responsible limits at any time. However, at this point, the vendor has made their final decision. If you believe their technical response is insufficient or are dissatisfied with the lack of response, direct that criticism to the Cosmos team—the decision-makers—not to me, as I have fulfilled my responsibilities as a researcher. I also want to make it clear that, in accordance with responsible disclosure (CVD) principles, I cannot share further details. While choosing to forgo a bounty and contribute to a patch for the sake of the community is commendable, criticizing an individual researcher’s principles and efforts based on only a partial understanding of the full context and the technical discussions with the vendor goes beyond ignorance—it is irresponsible. This is my final position, and I will not engage in any further unproductive debate.

@ehdus829 @cosmos There is a PR waiting for your review github.com/cometbft/comet…

@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.

Three audits. No bug bounty. AI-powered security scanner. vs. One audit. $500K active bounty. No AI tools. The second protocol is safer. Not even close. AI scanners find what they were trained on. Bug bounties incentivize people to find what nobody has thought of yet. You cannot train a model on the vulnerability that hasn't been discovered yet. You can pay a researcher to find it.

@__mxuse__ It seems like they did just reward your report, correct? But nothing surprising here.