I performed an audit on Builders Grants on January 6-7.
While reviewing the code I noticed that personal information such as telegram handles, personal google drive links and email addresses for grant recipients along with the grant reviewer feedback was exposed. I notified a steward from Public Goods Working Group about the issue. They noted the exposure of PII and passed the information to BuidlGuild team who developed the site.
The data exposure was then corrected and removed from the site. I asked if their would be a bounty or reward for it but since it was on the Builder ENS Grants page, it being qualified for a bounty was unknown. I then submitted it to Immunefi where it was ultimately rejected.
I understand that 'builder.ensgrants.xyz is not āENSā proper. But the site plays a crucial role as an extension thereof. I believe this should still be applicable for reward as the Bug Bounty clearly states that disclosure of user information is considered āHighā.
I am curious to know why this was not accepted as it is classified. Why would this not be an issue just because it doesnāt fall under ens.domains DNS, I believe that the applicability should still be extended as 'builder.ensgrants.xyz is an official part of ENS but not ENS proper,
Personal Data Exposure Shouldnāt get by into the public view and especially if that data is not yours, ours, mine etc.
I am officially asking to be retroactively rewarded for a bounty to be collectively decided from stewards. The reward payment scale overlaps each other so I am unsure on how to calculate what would be a fair reward.
On another noteā¦
Unfortunately, I am unable to message anyone through the discussion forum as all of my permissions and ability to message any persons has been taken away without any notification or discussion or consensus or real reasonāthat I am aware of at least. So I have to ask this publicly. Despite my continuing effort to contribute and take part in discussion over the past ~4 years, I donāt believe I have broken any rules and feel that I have been targeted because of a disagreement of my opinions and findings of discrepancy.
Hi @accessor.eth - Thank you for bringing this issue to our attention and for taking the time to conduct a security audit of the Builder Grants platform. We appreciate your diligence in identifying and reporting the exposure of personally identifiable information (PII).
Regarding the Bounty Request
To clarify the timeline and our position on this request:
When we received your report on January 7th, we promptly escalated the issue to the BuidlGuidl team, who took swift action and resolved the exposure within 12 hours.
On January 9th, we communicated that the Public Goods Working Group (PGWG) does not have an independent bounty program and suggested Immunefi as a potential avenue, though we were uncertain about eligibility which we communicated.
We were unaware of your Immunefi rejection until February 3rd, when you posted this on the forum.
Regarding the bounty classification, we acknowledge that ābuilder.ensgrants.xyzā is an extension of the ENS ecosystem, but it is not under ens.domains DNS nor part of the official ENS bug bounty scope. Immunefi, which operates with predefined criteria, seems to have determined that this issue was out of scope for a bounty.
That said, we do recognize your effort and contribution, and we acknowledge that your findings helped improve security. Given that PGWG does not have a structured bounty program, this required a steward-led discussion on whether a discretionary retroactive reward is a valid path in this case. We have concluded that an award of 2,500 USDC for this effort seems to be in line with the ENS Labs bug bounty classification which we consulted in making this decision.
Regarding forum permissions, we are unaware of the reason your permissions on the forum have been revoked. In the meantime, if you are unable to engage via the forum, feel free to reach out via other channels as you have done to report the bug, and we will ensure concerns are heard.
We appreciate your contributions to the ecosystem.
I appreciate the thoughtful recognition and the time spent in review by the PGWG. Contributing to ENS has been a key part of my Web3 journey, and I remain committed to its growth. ENS has played a pivotal role in shaping my understanding of cryptocurrency and decentralized technologies from the ground up.
Thanks, just FYI this report never made to us as it was filtered out automatically, which I think is fair based on the wording of the bug bounty program as is. We do however operate under āprimacy of impactā meaning there is room for considering the impact of a report even if it is technically out of scope. We will review the wording to make sure it better aligns with what the DAO considers as in scope.
I understand these concepts policies that bounty platforms implement. I donāt believe that there was anything unclear as a āparticipantā who is taking part. To be quite honest, I do things like this quite often. Personally, I believe that what ENS Labs has considered to be āin-scopeā should reflect the same across any other extensions of ENS.
Now that I am thinking about itāI think we should consider adding sister sites like ensgrants.xyz, or ensdao.org et al, to the āin-scopeā asset list. I canāt think of a reason to not. These assets are very close to those those who have access to sensitive ENS related matters and information. Often times those who have been privileged to have such access also have overlapping access ācross-platformā i.e, DAO > ENS Labs, Hosting or administration permissions and accounts etc. It would be very upsetting to see a security vulnerability to be exploited and cause damage that is not exactly immediately fixable --like a loss of funds; while an event like that could have been prevented by simply including said assets as in-scope. Iām not saying that this is something impending. I ignore issues everyday that I find because there is no incentive to or the process doesnāt warrant the time etc.
While I think the PG working group awarding a one-off bounty for this bug report is warranted, I feel pretty strongly that ancillary DAO sites should not be added to the Immunefi program. The scope and risk are very different, and the DAO would be less efficient if every piece of 3rd party tooling had to be reviewed as carefully as the protocol and manager app.
I think āin-scopeā should always be applicable to the assets that have the ability to potentially gain access to what is at risk by at least two degrees. I agree the risk of the platforms as themselves have separate primacy.
