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.
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.
@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.
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.
@eternalsakura13@l33d0hyun but there is already a CVE recorded for a bug with the same impact that occurred in the same component.
CVE-2025-24371 (https://t.co/9kAESxB935)
안녕하세요. 말씀하신 것처럼 검증자 노드와 릴레이 노드는 기본적으로 검증된 고정 피어만 사용합니다. 네 그래서 대부분 Sentry 노드 사용을 권장하며, Sentry 노드가 외부와 통신을 진행하는데 만약 해당 노드가 블록 동기화 중 교착된다면 검증자 노드나 릴레이 노드 전부 고립되게 됩니다. 그래서 이때는 공격 타겟을 Sentry 노드로 잡으면 공격을 성공시킬 수 있��니다.
주소록은 하나의 rpc url에다가 `net_info` 메소드를 한번 날려보세요. 쉽게 peer들의 rpc를 구할 수 있으며 구한 rpc들에게 `status`를 보내는 방식으로 네트워크에 있는 주소록을 리스트업할 수 있습니다.