Fwd: [FD] Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing Platform (EQS Group)

[Olle E Johansson]

Happy new CVE year!

I noticed this earlier today. A CVE for a SAAS service being withdrawn. Is this a good thing?

If I managed a complex IT platform with a few SAAS services being integrated, I would surely want to know if there is a problem and if it’s fixed. 

SAAS services can be mapped as dependencies in CycloneDX (if I remember correctly).

What do you think?

/O

Begin forwarded message:

From: Yuffie Kisaragi via Fulldisclosure <fulldis...@seclists.org>

Subject: [FD] Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing Platform (EQS Group)

Date: 4 January 2026 at 23:01:57 CET

To: "fulldis...@seclists.org" <fulldis...@seclists.org>, "security-vu...@eqs.com" <security-vu...@eqs.com>

Reply-To: Yuffie Kisaragi <yuffie....@atomicmail.io>

UPDATE:




Following the publication of these vulnerabilities and the subsequent CVE
assignments, the CVE identifiers have now been revoked.




The vendor (EQS Group) contacted the CVE Program (via a CNA) and disputed the
records, stating that the affected product is an exclusively hosted SaaS
platform with no customer-managed deployment or versioning. Based on this
argument, the CVE Program concluded that CVE assignment is “not a suitable
solution for vulnerability identification” in this case, as customers do not
take direct action to apply fixes.




In other words, because the service is centrally hosted and patched at the
provider’s discretion, the vulnerabilities are no longer considered eligible for
CVE tracking, despite being real, independently discovered, responsibly
disclosed, and acknowledged by the vendor.

The vendor has stated that fixes are being implemented and that private customer
notifications will be issued internally.




While remediation is of course welcome, this outcome highlights a broader issue:
vulnerabilities in SaaS platforms can effectively disappear from public
vulnerability tracking, simply because the deployment model removes user agency,
a model that arguably incentivizes security through obscurity, rather than
transparency.




The technical findings remain valid.




This update is shared purely for accuracy and record-keeping.

On Sun, Jan 4, 2026 at 4:40 PM <yuffie....@atomicmail.io
[yuffie....@atomicmail.io]> wrote:

UPDATE:


The reported vulnerabilities have now been assigned CVE identifiers:
CVE-2025-34411: https://www.cve.org/cverecord?id=CVE-2025-34411
[https://www.cve.org/cverecord?id=CVE-2025-34411]
CVE-2025-34412: https://www.cve.org/cverecord?id=CVE-2025-34412
[https://www.cve.org/cverecord?id=CVE-2025-34412]

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

[Jan Thielscher]

Hi Olle, 

thank you fro bringing this up. I do think, this is valid topic and worth a discussion. 

I fully agree with the statement, that it is not necessary for the customer of a SaaS to do much about a security finding or known vulnerability in a SaaS. It is out of his cause of action. There is not much the user can do about it. However, it still may be of interest to him, depending on what impact this may have to his processes/data operated through the SaaS.

Thus, I would distinguish between a, e.g. CSAF-report, from a provider outlining potential impacts to its customers due to a particular CVE-finding impacting the SaaS quality, integrity, availability, etc. and the reporting of a CVE for that particular SaaS, as we know it from components. 

Given a very advanced IT organization would look into the Service-BOMs of their suppliers, it might find a CVE in their BOM and thus, wanting to learn more about the state of remediation. But let’s be honest: How realistic is it, that you start requesting Service-BOMs? Whenever we integrate a SaaS, we request a C5 or ISO-Cert, showing the vendors efforts to keep their service clean. Then it is his responsibility. We have enough to care about our own stuff, that we can​ influence. 

Hence, I would consider the decision to keep SaaS issues out of CVE reporting is a good choice.

Looking forward for other people’s thoughts.

Mit freundlichem Gruß / best regards

Jan Thielscher

 

T: +49 69 153 227 750

F: +49 69 153 227 751

W: https://www.eacg.de

W: https://www.trustsource.io

Click HERE to arrange an Appointment

----

Enterprise Architecture Consulting Group

Taunustor 1 (TaunusTurm), 60310 Frankfurt am Main

EACG GmbH

Handelsregister Frankfurt am Main HRB 84852

Geschäftsführer: Jan Thielscher

 

--
--
Please also join the conversation on OWASP's Slack. https://owasp.org/slack/invite Join channel #cve-wg.
Web https://www.gvip-project.org
---
You received this message because you are subscribed to the Google Groups "CVE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cve+uns...@owasp.org.
To view this discussion visit https://groups.google.com/a/owasp.org/d/msgid/cve/001CAE98-C805-46EA-BE63-428DEFAAAFBE%40owasp.org.

[Olle E Johansson]

On 7 Jan 2026, at 11:22, 'Jan Thielscher' via CVE <c...@owasp.org> wrote:

Hi Olle, 

thank you fro bringing this up. I do think, this is valid topic and worth a discussion. 

I fully agree with the statement, that it is not necessary for the customer of a SaaS to do much about a security finding or known vulnerability in a SaaS. It is out of his cause of action. There is not much the user can do about it. However, it still may be of interest to him, depending on what impact this may have to his processes/data operated through the SaaS.

Thus, I would distinguish between a, e.g. CSAF-report, from a provider outlining potential impacts to its customers due to a particular CVE-finding impacting the SaaS quality, integrity, availability, etc. and the reporting of a CVE for that particular SaaS, as we know it from components. 

Given a very advanced IT organization would look into the Service-BOMs of their suppliers, it might find a CVE in their BOM and thus, wanting to learn more about the state of remediation. But let’s be honest: How realistic is it, that you start requesting Service-BOMs? Whenever we integrate a SaaS, we request a C5 or ISO-Cert, showing the vendors efforts to keep their service clean. Then it is his responsibility. We have enough to care about our own stuff, that we can​ influence. 

Hence, I would consider the decision to keep SaaS issues out of CVE reporting is a good choice.

Looking forward for other people’s thoughts.

Thank you for your response. To add to the discussion, there are CVEs for cloud services:

Let the discussion flow :-)

/O

To view this discussion visit https://groups.google.com/a/owasp.org/d/msgid/cve/AM9PR10MB497421C0403F6B168819E2DC8D84A%40AM9PR10MB4974.EURPRD10.PROD.OUTLOOK.COM.

[Tom Alrich]

Thanks for bring this to the OWASP group's attention, Olle. 

The purpose of reporting a vulnerability isn't just to warn customers so they can apply a patch or other mitigation if warranted. It's also to inform the software community in general of a vulnerability that might be in other products, both on premises and SaaS. That's why there needs to be some sort of notification.

However, the problem today is that most software developers/CNAs do not want to report a vulnerability in a SaaS product, since it would always be mitigated by the time the new CVE record appeared. They will try to make it clear by various other means that the vulnerability is mitigated and end users don't need to do anything (as Microsoft describes in their paper linked below), but it's inevitable that most end users (i.e., non-developers) will never notice that. All they'll see is that the SaaS product they use is affected by a new vulnerability.

It's ironic that Microsoft wrote that paper, since Lisa Olsen of Microsoft described during a presentation at the fall 2024 CNA Workshop how they were proposing a new CVE status other than "affected" or "not affected". It would be something like "Just FYI" or - my suggestion - "Don't worry, be happy! 🙂". I don't know what happened to that idea - it may just be in the queue for a future schema version - but that strikes me as the right way to do it. Otherwise, most SaaS providers probably will still not want to report vulnerabilities.

Tom Alrich LLC

312-515-8996

My blog has moved! It's now at https://tomalrich.substack.com/. All 1200+ of my posts since 2013 are accessible there, as well as new posts going forward.

I’m now in the training business! See this post for more information.

---

From: Olle E Johansson <olle.e.j...@owasp.org>
Sent: Wednesday, January 7, 2026 4:39 AM
To: c...@owasp.org <c...@owasp.org>
Cc: Jan Thielscher <jan.thi...@eacg.de>
Subject: Re: [OWASP CVE] [FD] Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing Platform (EQS Group)

 

To view this discussion visit https://groups.google.com/a/owasp.org/d/msgid/cve/5CA79230-6858-4E49-B210-4CD3FC37CCA6%40owasp.org.

[Olle E Johansson]

On 7 Jan 2026, at 17:35, Tom Alrich <t...@tomalrich.com> wrote:

Thanks for bring this to the OWASP group's attention, Olle. 

You’re welcome. This was brought to the OpenSSF vulnerability disclosures work group today, which resulted in this issue for further work:

Art Manion clearly said that the FD mail was wrong, that cloud/SAAS cve’s are encouraged in the CVE program database.

Thank you all for the feedback, let’s keep the discussion flowing!

The purpose of reporting a vulnerability isn't just to warn customers so they can apply a patch or other mitigation if warranted. It's also to inform the software community in general of a vulnerability that might be in other products, both on premises and SaaS. That's why there needs to be some sort of notification.

However, the problem today is that most software developers/CNAs do not want to report a vulnerability in a SaaS product, since it would always be mitigated by the time the new CVE record appeared. They will try to make it clear by various other means that the vulnerability is mitigated and end users don't need to do anything (as Microsoft describes in their paper linked below), but it's inevitable that most end users (i.e., non-developers) will never notice that. All they'll see is that the SaaS product they use is affected by a new vulnerability.

Well, let’s say that API version 2.0 to the cloud service had a serious issue and I need to move to 2.1 to avoid that

- could be that I 3rd party library I use needs an update or my own code.

So it’s not only web GUIs that get updated without me worrying.

/O

It's ironic that Microsoft wrote that paper, since Lisa Olsen of Microsoft described during a presentation at the fall 2024 CNA Workshop how they were proposing a new CVE status other than "affected" or "not affected". It would be something like "Just FYI" or - my suggestion - "Don't worry, be happy! 🙂". I don't know what happened to that idea - it may just be in the queue for a future schema version - but that strikes me as the right way to do it. Otherwise, most SaaS providers probably will still not want to report vulnerabilities.

Tom Alrich LLC

312-515-8996

My blog has moved! It's now at https://tomalrich.substack.com/. All 1200+ of my posts since 2013 are accessible there, as well as new posts going forward.

I’m now in the training business! See this post for more information.

---

From: Olle E Johansson <olle.e.j...@owasp.org>
Sent: Wednesday, January 7, 2026 4:39 AM
To: c...@owasp.org <c...@owasp.org>
Cc: Jan Thielscher <jan.thi...@eacg.de>
Subject: Re: [OWASP CVE] [FD] Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing Platform (EQS Group)

 

On 7 Jan 2026, at 11:22, 'Jan Thielscher' via CVE <c...@owasp.org> wrote:

Hi Olle, 

thank you fro bringing this up. I do think, this is valid topic and worth a discussion. 

I fully agree with the statement, that it is not necessary for the customer of a SaaS to do much about a security finding or known vulnerability in a SaaS. It is out of his cause of action. There is not much the user can do about it. However, it still may be of interest to him, depending on what impact this may have to his processes/data operated through the SaaS.

Thus, I would distinguish between a, e.g. CSAF-report, from a provider outlining potential impacts to its customers due to a particular CVE-finding impacting the SaaS quality, integrity, availability, etc. and the reporting of a CVE for that particular SaaS, as we know it from components. 

Given a very advanced IT organization would look into the Service-BOMs of their suppliers, it might find a CVE in their BOM and thus, wanting to learn more about the state of remediation. But let’s be honest: How realistic is it, that you start requesting Service-BOMs? Whenever we integrate a SaaS, we request a C5 or ISO-Cert, showing the vendors efforts to keep their service clean. Then it is his responsibility. We have enough to care about our own stuff, that we can​ influence. 

Hence, I would consider the decision to keep SaaS issues out of CVE reporting is a good choice.

Looking forward for other people’s thoughts.

Thank you for your response. To add to the discussion, there are CVEs for cloud services:

Toward greater transparency: Unveiling Cloud Service CVEs microsoft.com

<favicon.ico>

Please also join the conversation on OWASP's Slack. https://owasp.org/slack/inviteJoin channel #cve-wg.

Web https://www.gvip-project.org
--- 
You received this message because you are subscribed to the Google Groups "CVE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cve+uns...@owasp.org.

To view this discussion visit https://groups.google.com/a/owasp.org/d/msgid/cve/SJ0PR11MB49417364026377703260EFA9A884A%40SJ0PR11MB4941.namprd11.prod.outlook.com.