This is what I'd call "irresponsible disclosure" + disputing this CVE

[ThiefMaster]

First of all, the Indico repo has security reports enabled: https://github.com/indico/indico/security
The right thing would have been to open one there, and report this to us privately. You know, that's what people tend to call "responsible disclosure".

Then we could have told you, that we are aware of this endpoint, and we do not consider it a vulnerability.

Having this endpoint accessible by users is expected behavior because in a typical Indico instance users expect to be able to search other users by name, email etc. And of course that search endpoint could also be used to enumerate users just like the /api/principals one can.

That said, we do consider looking into ways (likely a setting) to restrict the search in the future so only those who really need it (e.g. event organizers) can use it, so instances where this behavior is not wanted/necessary can limit it, but for now it's all working as intended. Such a restriction would also apply to this endpoint. Because there can be cases where someone prefers to lock down their Indico instance more tightly and does not allow this "open" search for users.

Now, back to your security report... let me mention all the problems with it:

• You published a report and event requested a CVE without ever talking to us. This is incredibly rude, even more so towards an Open Source project (in case of certain companies with a very poor security track record, I would be more understanding of people just publishing vulns, instead of bothering with red tape etc). Now everyone who runs a security scanner or monitors CVEs gets pestered with an alert they can't really do anything about
• Because "Update to the Latest Version" is great advice in general, we actually urge people to update as soon as possible after a new release. But it's completely wrong here, just like the "Affected Versions: Indico v3.2.9 to v3.3.2" you listed. How did you even come up with this version range? The endpoint was added in v2.2 and still exists (v3.3.5).
• "Implement Input Validation" makes no sense here as well, even if this endpoint was supposed to be more protected, it's not a matter of (missing) input validation.
• "Monitor and Audit Logs" - how would you determine whether a request to that endpoint is malicious or not? Anyone who can manage some kind of content in Indico where they can edit the ACL uses the endpoint since the React-based component to edit ACLs uses it to map identifiers like User:123 to the actual user details shown in an ACL entry
• "Use a WAF" - a WAF would also not determine whether a request to that endpoint is "good" or "evil".
• "By modifying the User value (e.g., User:2302), the attacker can access data of another user." implies that the default would be to call this endpoint with the current user's ID, and get data for that user. This is not true. The current user is actually less common there than some other user.

Cheers
Adrian
Lead Developer of Indico

[cetinpy]

Hello Adrian, Thank you for your response. However, I would like to address a few points in your reply that seem contradictory or dismissive of the potential risks involved. Responsible Disclosure: While I understand the importance of responsible disclosure, your suggestion that publishing a CVE without prior communication is "incredibly rude" seems exaggerated, especially in the context of an open-source project. The CVE process exists to ensure transparency and accountability in the security ecosystem. Moreover, the decision to publish was based on the assumption that such a critical endpoint should not allow unrestricted access to user details by design. User Enumeration Risk: Allowing an endpoint to enumerate user details like names and emails without restrictions, even if "expected behavior," is inherently risky. This opens the door for attackers to abuse the functionality, especially in systems with sensitive user data. Version Discrepancies: If the endpoint has been present since version 2.2, as you mentioned, this does not invalidate the security implications. Instead, it highlights a long-standing issue that has remained unaddressed. I would encourage the team to take such findings seriously, as overlooking such risks can lead to reputational damage or regulatory concerns in the future. Tone of Response: While I appreciate your feedback, the tone of your message was unnecessarily harsh. Security researchers dedicate time and effort to identify and report vulnerabilities to improve overall security. Dismissing such efforts as "irresponsible" undermines the collaborative spirit of the security community. I would be happy to collaborate further to address this issue constructively, as I believe it is in everyone's best interest to maintain a secure environment for all users. Best regards Adrian ***@***.***>, 20 Oca 2025 Pzt, 17:49 tarihinde şunu yazdı:

…

First of all, the Indico repo has security reports enabled: https://github.com/indico/indico/security The right thing would have been to open one there, and report this to us privately. You know, that's what people tend to call "responsible disclosure". Then we could have told you, that we are aware of this endpoint, and we do not consider it a vulnerability. *Having this endpoint accessible by users is expected behavior because in a typical Indico instance users expect to be able to search other users by name, email etc. And of course that search endpoint could also be used to enumerate users just like the /api/principals one can.* *That said, we do consider looking into ways (likely a setting) to restrict the search in the future so only those who really need it (e.g. event organizers) can use it, so instances where this behavior is not wanted/necessary can limit it, but for now it's all working as intended. Such a restriction would also apply to this endpoint. Because there can be cases where someone prefers to lock down their Indico instance more tightly and does not allow this "open" search for users.* Now, back to your security report... let me mention all the problems with it: - You published a report and event requested a CVE without ever talking to us. This is *incredibly rude*, even more so towards an Open Source project (in case of certain companies with a very poor security track record, I would be more understanding of people just publishing vulns, instead of bothering with red tape etc). Now everyone who runs a security scanner or monitors CVEs gets pestered with an alert they can't really do anything about - Because "Update to the Latest Version" is great advice in general, we actually urge people to update as soon as possible after a new release. But it's completely wrong here, just like the "Affected Versions: Indico v3.2.9 to v3.3.2" you listed. How did you even come up with this version range? The endpoint was added in v2.2 and still exists (v3.3.5). - "Implement Input Validation" makes no sense here as well, even if this endpoint was supposed to be more protected, it's not a matter of (missing) input validation. - "Monitor and Audit Logs" - how would you determine whether a request to that endpoint is malicious or not? Anyone who can manage some kind of content in Indico where they can edit the ACL uses the endpoint since the React-based component to edit ACLs uses it to map identifiers like User:123 to the actual user details shown in an ACL entry - "Use a WAF" - a WAF would also not determine whether a request to that endpoint is "good" or "evil". - "By modifying the User value (e.g., User:2302), the attacker can access data of another user." implies that the default would be to call this endpoint with the current user's ID, and get data for that user. This is not true. The current user is actually less common there than some other user. Cheers Adrian Lead Developer of Indico — Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJX2MYEDLHADMHCMU2IBY4L2LUEJFAVCNFSM6AAAAABVQRQXTKVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44TSNBWGQ4DQNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ThiefMaster]

The CVE process exists to ensure transparency and accountability in the security ecosystem

Nothing wrong with that. In fact, we requested CVEs for Indico ourselves in the past. We did that after releasing a fixed version, so people seeing the CVE were immediately able to upgrade.

Moreover, the decision to publish was based on the assumption that such a critical endpoint should not allow unrestricted access to user details by design.

You consider it a very severe vulnerability - that's even more reason to responsibly disclose it privately to the developers first (and later go public in case of not getting any reactions there, which would not have been the case with is). Also my point above stands: By publishing a CVE + details immediately, you do not give people the opportunity to upgrade. But I think I can give you the benefit of the doubt here since you believed it's "fixed" in the latest version, meaning people should have already upgraded anyway.

Allowing an endpoint to enumerate user details like names and emails without restrictions, even if "expected behavior," is inherently risky. This opens the door for attackers to abuse the functionality, especially in systems with sensitive user data.

Querying data about my own account yields this:

{
        "affiliation": "CERN",
        "affiliation_id": null,
        "affiliation_meta": null,
        "avatar_url": "/user/42604/picture-3742796827/NDI2MDQ.UWhvn0u6GkRSv8SxruNB2iF9Z3U",
        "detail": "adrian.moennich@cern.ch (CERN)",
        "email": "adrian.moennich@cern.ch",
        "first_name": "Adrian",
        "identifier": "User:42604",
        "invalid": false,
        "last_name": "Mönnich",
        "name": "Adrian Mönnich",
        "title": "none",
        "type": "user",
        "user_id": 42604
    }

I don't see anything particularly sensitive. It's name, email and affiliation. Considering that academia/research is the main sector where Indico is used, this is information you can typically find about people with more or less a simple Google search.

If the endpoint has been present since version 2.2, as you mentioned, this
does not invalidate the security implications. Instead, it highlights a
long-standing issue that has remained unaddressed. I would encourage the
team to take such findings seriously, as overlooking such risks can lead to
reputational damage or regulatory concerns in the future.

My point was that the version range in your report is incorrect. And it was not meant to (in)validate anything, just pointing out something that's incorrect in your report. I'm still curious how you came up with the range though. Using some AI tool?

While I appreciate your feedback, the tone of your message was unnecessarily harsh.

Fair, it might have been a bit strongly worded, because instead of getting a proper responsible disclosure (via GitHub's security report feature, or even via good old email), I was randomly asked by someone about a CVE I wasn't even aware of at that moment. And without that email, I might not have found out about it for a much longer time.

And please imagine if this was an actual security bug, which we'd want to fix asap: By not notifying us, there would have been at least 4 days of this report being out in the open, without us even being able to start working on a fix! And it might have taken even longer, because it was pure coincidence that someone found your report while looking for something else and then reached out to us.

Security researchers dedicate time and effort to identify and report vulnerabilities to improve overall security.
Dismissing such efforts as "irresponsible" undermines the collaborative spirit of the security community.

My impression is that there are good ones who provide useful reports mainly focused on technical details about the vulnerability, and then those who aim mainly for a large number of CVEs attributed to them. For some reason, the reports from the latter also tend to contain more "fluff" (which I think may often be AI slop, or at least copy-pasted from OWASP et al), which means more text to read through instead of the actual details.

I would be happy to collaborate further to address this issue constructively, as I believe it is in everyone's best interest to maintain a secure environment for all users.

Honestly, I don't see much collaboration needed here. It's something we are aware of, and like I wrote in my original post, while we do not consider this a security vulnerability, it is something we want to improve nonetheless by giving Indico admins the choice on how "open" they want to be.

But for now, there is a CVE out there, which means people will be asking us for details (where we will basically tell them what I wrote in the two bold paragraphs in my first comment - just as we did in the past when someone asked, and typically people were fine with it!), and it also means that people running an Indico instance may get pestered by their security people who might also just look at open CVEs...

[cetinpy]

Thank you for taking the time to provide detailed feedback. I sincerely acknowledge that there was a communication gap in this process, and I should have reached out to the development team before publishing the CVE. I understand the value of direct collaboration in addressing such concerns effectively. My intention was always to highlight a potential risk and contribute constructively to improving security. I respect your perspective and the efforts your team has put into maintaining the integrity of Indico. I hope this discussion, despite the initial missteps, helps to enhance security practices further. Best regards Adrian ***@***.***>, 20 Oca 2025 Pzt, 19:23 tarihinde şunu yazdı:

…

The CVE process exists to ensure transparency and accountability in the security ecosystem Nothing wrong with that. In fact, we requested CVEs for Indico ourselves <https://github.com/indico/indico/security/advisories> in the past. We did that *after* releasing a fixed version, so people seeing the CVE were immediately able to upgrade. Moreover, the decision to publish was based on the assumption that such a critical endpoint should not allow unrestricted access to user details by design. You consider it a very severe vulnerability - that's even more reason to responsibly disclose it privately to the developers first (and later go public in case of not getting any reactions there, which would not have been the case with is). Also my point above stands: By publishing a CVE + details immediately, you do not give people the opportunity to upgrade. But I think I can give you the benefit of the doubt here since you believed it's "fixed" in the latest version, meaning people should have already upgraded anyway. Allowing an endpoint to enumerate user details like names and emails without restrictions, even if "expected behavior," is inherently risky. This opens the door for attackers to abuse the functionality, especially in systems with sensitive user data. Querying data about my own account yields this: { "affiliation": "CERN", "affiliation_id": null, "affiliation_meta": null, "avatar_url": "/user/42604/picture-3742796827/NDI2MDQ.UWhvn0u6GkRSv8SxruNB2iF9Z3U", "detail": ***@***.*** (CERN)", "email": ***@***.***", "first_name": "Adrian", "identifier": "User:42604", "invalid": false, "last_name": "Mönnich", "name": "Adrian Mönnich", "title": "none", "type": "user", "user_id": 42604 } I don't see anything particularly sensitive. It's name, email and affiliation. Considering that academia/research is the main sector where Indico is used, this is information you can typically find about people with more or less a simple Google search. If the endpoint has been present since version 2.2, as you mentioned, this does not invalidate the security implications. Instead, it highlights a long-standing issue that has remained unaddressed. I would encourage the team to take such findings seriously, as overlooking such risks can lead to reputational damage or regulatory concerns in the future. My point was that the version range in your report is incorrect. And it was not meant to (in)validate anything, just pointing out something that's incorrect in your report. I'm still curious how you came up with the range though. Using some AI tool? While I appreciate your feedback, the tone of your message was unnecessarily harsh. Fair, it might have been a bit strongly worded, because instead of getting a proper responsible disclosure (via GitHub's security report feature, or even via good old email), I was randomly asked by someone about a CVE I wasn't even aware of at that moment. And without that email, I might not have found out about it for a much longer time. And please imagine if this was an actual security bug, which we'd want to fix asap: By not notifying us, there would have been at least 4 days of this report being out in the open, without us even being able to start working on a fix! And it might have taken even longer, because it was pure coincidence that someone found your report while looking for something else and then reached out to us. Security researchers dedicate time and effort to identify and report vulnerabilities to improve overall security. Dismissing such efforts as "irresponsible" undermines the collaborative spirit of the security community. My impression is that there are good ones who provide useful reports mainly focused on technical details about the vulnerability, and then those who aim mainly for a large number of CVEs attributed to them. For some reason, the reports from the latter also tend to contain more "fluff" (which I think may often be AI slop, or at least copy-pasted from OWASP et al), which means more text to read through instead of the actual details. I would be happy to collaborate further to address this issue constructively, as I believe it is in everyone's best interest to maintain a secure environment for all users. Honestly, I don't see much collaboration needed here. It's something we are aware of, and like I wrote in my original post, while we do not consider this a security vulnerability, it is something we want to improve nonetheless by giving Indico admins the choice on how "open" they want to be. But for now, there is a CVE out there, which means people will be asking us for details (where we will basically tell them what I wrote in the two bold paragraphs in my first comment - just as we did in the past when someone asked, and typically people were fine with it!), and it also means that people running an Indico instance may get pestered by their security people who might also just look at open CVEs... — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJX2MYBL632T3DNL26K33HT2LUPIDAVCNFSM6AAAAABVQRQXTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBSHAZTCMRRGM> . You are receiving this because you commented.Message ID: ***@***.***>

[ThiefMaster]

Thanks for understanding, no hard feelings.

PS: Still curious how you came up with the version range though :)

[cetinpy]

Thank you for your response! Regarding the version range, I determined it based on a combination of my own testing and publicly available documentation. During my assessment, I tested versions v3.2.9 to v3.3.2, and the behavior appeared consistent across these versions. However, I acknowledge that my testing might not cover all potential variations or configurations. If you have more precise information about the versions impacted, I would greatly appreciate it and would be happy to update the report accordingly. My goal is to ensure the report is as accurate and helpful as possible. Adrian ***@***.***>, 20 Oca 2025 Pzt, 19:47 tarihinde şunu yazdı:

…

Thanks for understanding, no hard feelings. PS: Still curious how you came up with the version range though :) — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJX2MYGDAFGZ36BKBAB2HOL2LUSCPAVCNFSM6AAAAABVQRQXTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBSHA3TSNZUGQ> . You are receiving this because you commented.Message ID: ***@***.***>