GCVE-1988-2026-0185
Vulnerability from gna-1988 – Published: 2026-09-08 07:57 – Updated: 2026-09-08 07:57
VLAI
EPSS
VEX
Title
Re: Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing Platform (EQS Group)
Summary
Hello everyone,
Kindly let me introduce myself. This is the first – and potentially, last – message on this mailing list. I am Marco,
the CISO of EQS Group. Kindly allow me to address some of the statements expressed publicly here.
About the Convercent application
Convercent was acquired by OneTrust in 2021, and in turn, EQS has acquired it from OneTrust at the end of 2024. Before
being acquired by EQS, the Convercent application has not received much love in the latest years, and EQS has since
then proceeded to migrate its customers to the EQS Compliance COCKPIT, which is a modern, supported, and secure SaaS.
The Convercent application is sunset and will be finally switched off by mid of 2026.
Currently, Convercent is supported by EQS on a best-effort basis; despite that, EQS Group has committed to fix all
critical vulnerabilities until the last customer is fully migrated. We want our customers to migrate to our best
service because it is better – not rush them in our new product because what we inherited from an acquisition is
insecure.
The vulnerabilities
The two issues disclosed are either minor in nature or do not constitute vulnerabilities. One was a lack of certain
HTTP headers (some of the reported ones where wrong, but regardless, still hardly something CVE-worthy), and the second
was about an “exposed” API; however, it is public by design as this is how the application works: it is a page where
customers – who have explicitly agreed and signed off to be present – are added to a drop-down list, fed from this
public API. The web page exposes the list of customers by design.
While we may reasonably question whether this page reflects current secure-by-design standards, this brings zero added
risk to any of the EQS customers and Convercent users.
I strongly disagree with the ideas that those “vulnerabilities” could become CVEs – regardless of the status of the
SaaS security and how CVEs are handled. Therefore, we proceeded to ask for their removal from the CVSS database, so not
to alarm our customers with false positives. The responsible CNA agreed immediately to remove them (thank you very
much, VulnCheck!).
Communication with our customers
EQS Group communicates with its customers through established and appropriate channels – notably, our Trust Center –
and not via anonymous mailing lists. Customers have received and will continue to receive all the notifications they
have contractually required to obtain, and where relevant, additional context beyond those obligations.
Customers have received a briefing about the activity happening on this mailing list via our Trust Center.
The status of SaaS Security
As EQS Group is a CNA candidate, we participate and closely follow discussions between MITRE, CISA, and the German BSI,
about vulnerability reporting for SaaS. While we have not heard any news on this front since the last two years, EQS
Group remains committed to aligning with applicable best practices as they evolve.
We believe that meaningful progress in SaaS security is best achieved through structured, collaborative forums with
clear governance, rather than responding to ad-hoc reports of unvetted findings. EQS Group already participates to
proper, professional working groups on SaaS security, for instance through the Cloud Security Alliance. If other
working groups will emerge through any of the official organisms already mentioned, we will certainly participate.
In general, as a principle, CVEs have been created many years ago, at a time where “the Cloud” did not exist in its
current form. They were conceived so that users who procured a software from a development company and installed it on
their system, could be notified when the software they have installed, manifested a security issue. In that way, they
could procure the patch and fix it before a misuse could happen.
Now, except for very particular and edge cases, this is largely inapplicable to SaaS, where there is very little users
can do and solely rely on the Cloud Service Provider to fix any vulnerability. There is almost never any real ground
for a SaaS provider to notify a customer – unless of course a breach has been detected, but in that case we are way
beyond a CVE and we are on a different territory. For a SaaS, even knowing that the application had a bug, does not
help the user in any way. This is why typically CVEs as a concept are not the proper tool to address SaaS
vulnerabilities, and in general, rushing to disclose them only damages the users; a disclosure does not help them in
any way.
Response to the “Responsible" Disclosure
About the “responsible" disclosure: EQS Group receives a significant volume of “vulnerability notifications” like that
one. Almost all of them are low or irrelevant issues from anonymous users looking to make a buck; they are typically
about a missing HTTP headers or lack of optional DNS records. Given the scale of our environment, it can happen that
some record is not updated, but this has little relevance to the security of our platforms. We also cannot always reply
to all those messages, and most of them seem AI or automatically generated.
The notification from “Yuffie Kisaragi” was sent to us on the 4th of December and went to Junk due to the low
reputation of the email used. The author then rushed to obtain two CVE IDs less than two weeks later and subsequently
lost no time posting them on this list.
EQS Group is certainly not perfect, but if these would have been real vulnerabilities, I argue that this would have not
qualified as a “responsible” disclosure by any reasonable standard.
Further communications
EQS Group’s vulnerability handling policy is listed here<https://www.eqs.com/report-a-vulnerability/#handle> –
https://www.eqs.com/report-a-vulnerability/ – and we strongly suggest anyone to read it before they issue a report.
In this regard, we would like to point out the followings:
1. For several reasons – legal, commercial, policy, and ethical – EQS Group is unable to respond to requests for
payment of bounties outside of an official bug bounty program.
2. EQS Group does nor remunerate bugs that were already discovered internally and were already in resolution.
3. EQS Group strongly discourages non-approved, un-vetted testing on EQS Group’s infrastructure. They can and will
be perceived as hostile activity. Testing is encouraged only within officially approved bug bounty programs, in respect
to the established rules of engagement.
4. Kindly avoid pointless reports on MTA-STS records, DMARC, quantum ciphers, and other junk like that. It makes our
life easier.
Thank you for your attention.
Best regards / mit freundlichen Grüßen / Cordiali saluti
Dr Marco Ermini (He/Him)
Chief Information Security Officer (CISO)
Marco.Ermini () eqs com<mailto:Marco.Ermini () eqs com;>
[LinkendIn]<https://www.linkedin.com/in/marcoermini/>
Vereinbaren Sie einen Termin mit mir<https://outlook.office365.com/owa/calendar/BookaMeetingwithMarco () eqs
com/bookings/>
[EQS Group Logo]<https://www.eqs.com/?keyword=email-footer>
[EQS Compliance COCKPIT]<https://www.eqs.com/de/platform-compliance-ethics/?keyword=email-footer>
EQS Group GmbH | Karlstr. 47 | 80333 München | www.eqs.com<https://www.eqs.com/?keyword=email-footer> |
www.integrityline.com<http://www.integrityline.com/?keyword=email-footer>
[linkedIn Logo]<https://www.linkedin.com/company/1273779>
[X Logo]<https://twitter.com/eqsgroup>
[Instagram Logo]<https://www.instagram.com/eqsgroup/>
[YouTube Logo]<https://www.youtube.com/user/EquityStory>
[RSS Logo]<https://www.eqs.com/compliance-knowledge/>
[Xing Logo]<https://www.xing.com/companies/eqsgroup>
Register Court: Munich | Register Number: HRB 297048
Managing Directors: Achim Weick (CEO), André Silverio Marques, Marcus Sultzer
The preceding email message contains information that is confidential and may constitute non-public information that is
intended to be conveyed only to the designated recipient(s).
If you are not an intended recipient of this message, please notify the sender at +49 89 444430-000<tel:+4989444430000>.
Unauthorized use, dissemination, distribution, or reproduction of this message is strictly prohibited and may be
unlawful.
From: Wade Sparks <wsparks () vulncheck com>
Date: Wednesday, 21. January 2026 at 17:29
To: Yuffie Kisaragi <yuffie.kisaragi () atomicmail io>
Cc: Security Vulnerability <security-vulnerability () eqs com>, fulldisclosure () seclists org <fulldisclosure ()
seclists org>
Subject: Re: Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing
Platform (EQS Group)
EXTERNAL EMAIL WARNING: Please check the sender of the message
Hello Yuffie,
Upon further investigation, the VulnCheck CNA determined that these vulnerabilities were not suitable for CVE
assignment. The vulnerabilities exist within a SaaS product and are mitigated at the CSP-level which in this case,
would be the vendor, EQS Group. Rather than contribute unactionable CVE records, the VulnCheck CNA used its
discretionary prowess to move forward with rejecting these records. This policy aligns with a 2022 blog from
MITRE<https://www.cve.org/Media/News/item/blog/2022/09/13/Dispelling-the-Myth-CVE-ID>. It should be noted that the
vendor informed us that they have published advisories for the respective vulnerabilities in their "Trust Center"
customer portal.
These actions should not be a deterrent for you to pursue CVE assignment through MITRE or another research CNA.
Best regards,
[https://lh7-us.googleusercontent.com/-9dCGnQIZaW0ehyK1B0bqLmef7d7ZWuSmmmWUYJGhzNgtzRhqFPZrtO3AnQt8PETFHiv6_YST3DacZVgrxPdAYXErAMnJrF6Isn27caszruLjby7jLRuuU__5emkqFjU8hczQ307--yVVMpVSiK7Qg]<https://www.vulncheck.com/>
Wade Sparks III
VulnCheck
Senior Vulnerability Analyst
On Tue, Jan 20, 2026 at 12:13 PM Yuffie Kisaragi <yuffie.kisaragi () atomicmail io<mailto:yuffie.kisaragi () atomicmail
io>> wrote:
Dear Art,
Thank you for sharing your detailed evaluation and for pointing out the relevant sections of the CNA Rules.
Your argument is well reasoned, particularly with respect to the current guidance on SaaS and exclusively hosted
services.
I have forwarded your evaluation to the CNA for further consideration. It will also be important to understand the
vendor’s perspective in light of the points you raised, especially regarding the applicability of the
“exclusively-hosted-service” tag and the removal of prior restrictions.
We look forward to receive transparent feedback from the CNA and/or the vendor.
To date, the vendor has remained silent with regard to informing their users about the reported issues. As far as we
can determine, no public advisory or user-facing communication has been issued via their vulnerability reporting
channel (https://www.eqs.com/report-a-vulnerability/) or elsewhere.
Best regards,
Yuffie
On Tue, Jan 20, 2026 at 7:26 PM <zmanion () protonmail com<mailto:zmanion () protonmail com>> wrote:
Hi,
the vulnerabilities are no longer considered eligible for CVE tracking, despite being real, independently discovered,
responsibly disclosed, and acknowledged by the vendor.
CVE IDs *can* be assigned for SaaS or similarly "cloud only" software. For a period of time, there was a restriction
that only the provider could make or request such an assignment. But the current CVE rules remove this restriction:
4.2.3 CNAs MUST NOT consider the type of technology (e.g., cloud, on-premises, artificial intelligence, machine
learning) as the sole basis for determining assignment.
It would have been acceptable (even preferred) to leave CVE-2025-34411 and CVE-2025-34412 published and identify them
as affecting an "exclusively-hosted-service:"
5.1.11.1 (A CVE Record) MUST use the “exclusively-hosted-service” tag when all known Products listed in the CVE Record
exist only as fully
Severity
No CVSS data available.
Assigner
References
21 references
Impacted products
Relationships
reference
GCVE-1988-2026-0185 (this record)
- related CVE-2025-34411
- related CVE-2025-34412
{
"containers": {
"cna": {
"affected": [
{
"product": "unknown",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Marco Ermini via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Hello everyone,\n\n\n\nKindly let me introduce myself. This is the first \u2013 and potentially, last \u2013 message on this mailing list. I am Marco, \nthe CISO of EQS Group. Kindly allow me to address some of the statements expressed publicly here.\n\n\n\nAbout the Convercent application\n\n\n\nConvercent was acquired by OneTrust in 2021, and in turn, EQS has acquired it from OneTrust at the end of 2024. Before \nbeing acquired by EQS, the Convercent application has not received much love in the latest years, and EQS has since \nthen proceeded to migrate its customers to the EQS Compliance COCKPIT, which is a modern, supported, and secure SaaS. \nThe Convercent application is sunset and will be finally switched off by mid of 2026.\n\n\n\nCurrently, Convercent is supported by EQS on a best-effort basis; despite that, EQS Group has committed to fix all \ncritical vulnerabilities until the last customer is fully migrated. We want our customers to migrate to our best \nservice because it is better \u2013 not rush them in our new product because what we inherited from an acquisition is \ninsecure.\n\n\n\n\n\nThe vulnerabilities\n\n\n\nThe two issues disclosed are either minor in nature or do not constitute vulnerabilities. One was a lack of certain \nHTTP headers (some of the reported ones where wrong, but regardless, still hardly something CVE-worthy), and the second \nwas about an \u201cexposed\u201d API; however, it is public by design as this is how the application works: it is a page where \ncustomers \u2013 who have explicitly agreed and signed off to be present \u2013 are added to a drop-down list, fed from this \npublic API. The web page exposes the list of customers by design.\n\n\n\nWhile we may reasonably question whether this page reflects current secure-by-design standards, this brings zero added \nrisk to any of the EQS customers and Convercent users.\n\n\n\nI strongly disagree with the ideas that those \u201cvulnerabilities\u201d could become CVEs \u2013 regardless of the status of the \nSaaS security and how CVEs are handled. Therefore, we proceeded to ask for their removal from the CVSS database, so not \nto alarm our customers with false positives. The responsible CNA agreed immediately to remove them (thank you very \nmuch, VulnCheck!).\n\n\n\n\n\nCommunication with our customers\n\n\n\nEQS Group communicates with its customers through established and appropriate channels \u2013 notably, our Trust Center \u2013 \nand not via anonymous mailing lists. Customers have received and will continue to receive all the notifications they \nhave contractually required to obtain, and where relevant, additional context beyond those obligations.\n\n\n\nCustomers have received a briefing about the activity happening on this mailing list via our Trust Center.\n\n\n\n\n\nThe status of SaaS Security\n\n\n\nAs EQS Group is a CNA candidate, we participate and closely follow discussions between MITRE, CISA, and the German BSI, \nabout vulnerability reporting for SaaS. While we have not heard any news on this front since the last two years, EQS \nGroup remains committed to aligning with applicable best practices as they evolve.\n\n\nWe believe that meaningful progress in SaaS security is best achieved through structured, collaborative forums with \nclear governance, rather than responding to ad-hoc reports of unvetted findings. EQS Group already participates to \nproper, professional working groups on SaaS security, for instance through the Cloud Security Alliance. If other \nworking groups will emerge through any of the official organisms already mentioned, we will certainly participate.\n\n\nIn general, as a principle, CVEs have been created many years ago, at a time where \u201cthe Cloud\u201d did not exist in its \ncurrent form. They were conceived so that users who procured a software from a development company and installed it on \ntheir system, could be notified when the software they have installed, manifested a security issue. In that way, they \ncould procure the patch and fix it before a misuse could happen.\n\n\nNow, except for very particular and edge cases, this is largely inapplicable to SaaS, where there is very little users \ncan do and solely rely on the Cloud Service Provider to fix any vulnerability. There is almost never any real ground \nfor a SaaS provider to notify a customer \u2013 unless of course a breach has been detected, but in that case we are way \nbeyond a CVE and we are on a different territory. For a SaaS, even knowing that the application had a bug, does not \nhelp the user in any way. This is why typically CVEs as a concept are not the proper tool to address SaaS \nvulnerabilities, and in general, rushing to disclose them only damages the users; a disclosure does not help them in \nany way.\n\n\n\n\nResponse to the \u201cResponsible\" Disclosure\n\n\n\nAbout the \u201cresponsible\" disclosure: EQS Group receives a significant volume of \u201cvulnerability notifications\u201d like that \none. Almost all of them are low or irrelevant issues from anonymous users looking to make a buck; they are typically \nabout a missing HTTP headers or lack of optional DNS records. Given the scale of our environment, it can happen that \nsome record is not updated, but this has little relevance to the security of our platforms. We also cannot always reply \nto all those messages, and most of them seem AI or automatically generated.\n\n\n\nThe notification from \u201cYuffie Kisaragi\u201d was sent to us on the 4th of December and went to Junk due to the low \nreputation of the email used. The author then rushed to obtain two CVE IDs less than two weeks later and subsequently \nlost no time posting them on this list.\n\n\n\nEQS Group is certainly not perfect, but if these would have been real vulnerabilities, I argue that this would have not \nqualified as a \u201cresponsible\u201d disclosure by any reasonable standard.\n\n\n\nFurther communications\n\n\nEQS Group\u2019s vulnerability handling policy is listed here\u003chttps://www.eqs.com/report-a-vulnerability/#handle\u003e \u2013 \nhttps://www.eqs.com/report-a-vulnerability/ \u2013 and we strongly suggest anyone to read it before they issue a report.\n\n\n\nIn this regard, we would like to point out the followings:\n\n 1. For several reasons \u2013 legal, commercial, policy, and ethical \u2013 EQS Group is unable to respond to requests for \npayment of bounties outside of an official bug bounty program.\n 2. EQS Group does nor remunerate bugs that were already discovered internally and were already in resolution.\n 3. EQS Group strongly discourages non-approved, un-vetted testing on EQS Group\u2019s infrastructure. They can and will \nbe perceived as hostile activity. Testing is encouraged only within officially approved bug bounty programs, in respect \nto the established rules of engagement.\n 4. Kindly avoid pointless reports on MTA-STS records, DMARC, quantum ciphers, and other junk like that. It makes our \nlife easier.\n\n\n\nThank you for your attention.\n\nBest regards / mit freundlichen Gr\u00fc\u00dfen / Cordiali saluti\n\nDr Marco Ermini (He/Him)\nChief Information Security Officer (CISO)\n\nMarco.Ermini () eqs com\u003cmailto:Marco.Ermini () eqs com;\u003e\n\n[LinkendIn]\u003chttps://www.linkedin.com/in/marcoermini/\u003e\nVereinbaren Sie einen Termin mit mir\u003chttps://outlook.office365.com/owa/calendar/BookaMeetingwithMarco () eqs \ncom/bookings/\u003e\n[EQS Group Logo]\u003chttps://www.eqs.com/?keyword=email-footer\u003e\n\n[EQS Compliance COCKPIT]\u003chttps://www.eqs.com/de/platform-compliance-ethics/?keyword=email-footer\u003e\nEQS Group GmbH | Karlstr. 47 | 80333 M\u00fcnchen | www.eqs.com\u003chttps://www.eqs.com/?keyword=email-footer\u003e | \nwww.integrityline.com\u003chttp://www.integrityline.com/?keyword=email-footer\u003e\n[linkedIn Logo]\u003chttps://www.linkedin.com/company/1273779\u003e\n[X Logo]\u003chttps://twitter.com/eqsgroup\u003e\n[Instagram Logo]\u003chttps://www.instagram.com/eqsgroup/\u003e\n[YouTube Logo]\u003chttps://www.youtube.com/user/EquityStory\u003e\n[RSS Logo]\u003chttps://www.eqs.com/compliance-knowledge/\u003e\n[Xing Logo]\u003chttps://www.xing.com/companies/eqsgroup\u003e\nRegister Court: Munich | Register Number: HRB 297048\nManaging Directors: Achim Weick (CEO), Andr\u00e9 Silverio Marques, Marcus Sultzer\n\nThe preceding email message contains information that is confidential and may constitute non-public information that is \nintended to be conveyed only to the designated recipient(s).\nIf you are not an intended recipient of this message, please notify the sender at +49 89 444430-000\u003ctel:+4989444430000\u003e.\nUnauthorized use, dissemination, distribution, or reproduction of this message is strictly prohibited and may be \nunlawful.\n\n\nFrom: Wade Sparks \u003cwsparks () vulncheck com\u003e\nDate: Wednesday, 21. January 2026 at 17:29\nTo: Yuffie Kisaragi \u003cyuffie.kisaragi () atomicmail io\u003e\nCc: Security Vulnerability \u003csecurity-vulnerability () eqs com\u003e, fulldisclosure () seclists org \u003cfulldisclosure () \nseclists org\u003e\nSubject: Re: Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing \nPlatform (EQS Group)\n\n\nEXTERNAL EMAIL WARNING: Please check the sender of the message\n\nHello Yuffie,\n\nUpon further investigation, the VulnCheck CNA determined that these vulnerabilities were not suitable for CVE \nassignment. The vulnerabilities exist within a SaaS product and are mitigated at the CSP-level which in this case, \nwould be the vendor, EQS Group. Rather than contribute unactionable CVE records, the VulnCheck CNA used its \ndiscretionary prowess to move forward with rejecting these records. This policy aligns with a 2022 blog from \nMITRE\u003chttps://www.cve.org/Media/News/item/blog/2022/09/13/Dispelling-the-Myth-CVE-ID\u003e. It should be noted that the \nvendor informed us that they have published advisories for the respective vulnerabilities in their \"Trust Center\" \ncustomer portal.\n\nThese actions should not be a deterrent for you to pursue CVE assignment through MITRE or another research CNA.\n\nBest regards,\n\n[https://lh7-us.googleusercontent.com/-9dCGnQIZaW0ehyK1B0bqLmef7d7ZWuSmmmWUYJGhzNgtzRhqFPZrtO3AnQt8PETFHiv6_YST3DacZVgrxPdAYXErAMnJrF6Isn27caszruLjby7jLRuuU__5emkqFjU8hczQ307--yVVMpVSiK7Qg]\u003chttps://www.vulncheck.com/\u003e\n\nWade Sparks III\n\nVulnCheck\nSenior Vulnerability Analyst\n\n\nOn Tue, Jan 20, 2026 at 12:13\u202fPM Yuffie Kisaragi \u003cyuffie.kisaragi () atomicmail io\u003cmailto:yuffie.kisaragi () atomicmail \nio\u003e\u003e wrote:\n\n\nDear Art,\n\n\nThank you for sharing your detailed evaluation and for pointing out the relevant sections of the CNA Rules.\n\n\nYour argument is well reasoned, particularly with respect to the current guidance on SaaS and exclusively hosted \nservices.\n\n\nI have forwarded your evaluation to the CNA for further consideration. It will also be important to understand the \nvendor\u2019s perspective in light of the points you raised, especially regarding the applicability of the \n\u201cexclusively-hosted-service\u201d tag and the removal of prior restrictions.\n\nWe look forward to receive transparent feedback from the CNA and/or the vendor.\n\nTo date, the vendor has remained silent with regard to informing their users about the reported issues. As far as we \ncan determine, no public advisory or user-facing communication has been issued via their vulnerability reporting \nchannel (https://www.eqs.com/report-a-vulnerability/) or elsewhere.\n\nBest regards,\n\nYuffie\n\nOn Tue, Jan 20, 2026 at 7:26 PM \u003czmanion () protonmail com\u003cmailto:zmanion () protonmail com\u003e\u003e wrote:\n\nHi,\n\nthe vulnerabilities are no longer considered eligible for CVE tracking, despite being real, independently discovered, \nresponsibly disclosed, and acknowledged by the vendor.\nCVE IDs *can* be assigned for SaaS or similarly \"cloud only\" software. For a period of time, there was a restriction \nthat only the provider could make or request such an assignment. But the current CVE rules remove this restriction:\n\n4.2.3 CNAs MUST NOT consider the type of technology (e.g., cloud, on-premises, artificial intelligence, machine \nlearning) as the sole basis for determining assignment.\n\nIt would have been acceptable (even preferred) to leave CVE-2025-34411 and CVE-2025-34412 published and identify them \nas affecting an \"exclusively-hosted-service:\"\n\n5.1.11.1 (A CVE Record) MUST use the \u201cexclusively-hosted-service\u201d tag when all known Products listed in the CVE Record \nexist only as fully"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-08T07:57:41Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jan/25"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Jan/25"
},
{
"url": "http://www.integrityline.com/?keyword=email-footer"
},
{
"url": "https://lh7-us.googleusercontent.com/-9dCGnQIZaW0ehyK1B0bqLmef7d7ZWuSmmmWUYJGhzNgtzRhqFPZrtO3AnQt8PETFHiv6_YST3DacZVgrxPdAYXErAMnJrF6Isn27caszruLjby7jLRuuU__5emkqFjU8hczQ307--yVVMpVSiK7Qg"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://outlook.office365.com/owa/calendar/BookaMeetingwithMarco"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://twitter.com/eqsgroup"
},
{
"url": "https://www.cve.org/Media/News/item/blog/2022/09/13/Dispelling-the-Myth-CVE-ID"
},
{
"url": "https://www.cve.org/resourcessupport/allresources/cnarules"
},
{
"url": "https://www.eqs.com/?keyword=email-footer"
},
{
"url": "https://www.eqs.com/compliance-knowledge/"
},
{
"url": "https://www.eqs.com/de/platform-compliance-ethics/?keyword=email-footer"
},
{
"url": "https://www.eqs.com/report-a-vulnerability/"
},
{
"url": "https://www.eqs.com/report-a-vulnerability/#handle"
},
{
"url": "https://www.instagram.com/eqsgroup/"
},
{
"url": "https://www.linkedin.com/company/1273779"
},
{
"url": "https://www.linkedin.com/in/marcoermini/"
},
{
"url": "https://www.vulncheck.com/"
},
{
"url": "https://www.xing.com/companies/eqsgroup"
},
{
"url": "https://www.youtube.com/user/EquityStory"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Jan/25"
],
"discovery": "EXTERNAL"
},
"title": "Re: Multiple Security Misconfigurations and Customer Enumeration Exposure in Convercent Whistleblowing Platform (EQS Group)",
"x_gcve": [
{
"recordType": "reference",
"relationships": [
{
"destId": "CVE-2025-34411",
"type": "related"
},
{
"destId": "CVE-2025-34412",
"type": "related"
}
],
"vulnId": "GCVE-1988-2026-0185",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jan/25",
"automated": true,
"contentSha256": "5706daeae34135987f816ff9f75eb733cc5a660d5099b81280a650892732ead3",
"evidenceScore": 5,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Jan/25",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-01-23T18:41:47Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0185"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-08T07:57:41Z",
"dateUpdated": "2026-09-08T07:57:41Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0185"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…