Security Advisory: Chaining XSS, Database Exposure, and GDPR Violations in Devcomm BIP CMS

Author: Varun Singh Chauhan | Vrunsec.in | Security Researcher
Target: Devcomm BIP CMS & Sygnalista (Whistleblower Module)
Impacted Scope: 40+ Regional Government Portals in Poland (e.g., koscierzyna.e-bip.eu)
Tracking ID: CERT.PL #5633695

Executive Summary

During an independent security assessment of Polish public sector infrastructure, I identified a critical multi-vector attack chain affecting vendor-managed government web applications.

What began as routine reconnaissance escalated into the discovery of 40 active government web portals. Thirty-six of these instances were operating the legacy Devcomm BIP CMS, vulnerable to Unauthenticated Reflected XSS and Database Information Exposure. The remaining four portals hosted a newly deployed "Sygnalista" whistleblower module, which suffered from a severe GDPR/PII violation via API over-fetching.

Following an exhaustive Coordinated Vulnerability Disclosure (CVD) process with CERT Polska (CERT.PL)—spanning 50 active days and over 30 email exchanges—these findings forced a massive infrastructure migration by the vendor. Despite intense bureaucratic hurdles and CVE rule loopholes utilized by the vendor to avoid public tracking, the disclosure undeniably secured the data and privacy of dozens of government institutions.

Technical Breakdown

1. Reconnaissance: The 10th Tab

The initial phase involved mapping the external attack surface of the vendor's provided infrastructure. Subdomain enumeration revealed 40 distinct public-facing portals utilized by various regional government bodies. The infrastructure was bifurcated between legacy Devcomm CMS instances and the newly deployed Sygnalista whistleblower platforms.

The assessment began with routine Google Dorking for SQL Injection vulnerabilities across Polish domains. After testing multiple targets without success, I was on my tenth tab and ready to power off my PC for the day. Right before quitting, I noticed a search function on a Devcomm BIP CMS portal. I decided to test a simple HTML injection using an underline tag (<u>). To my surprise, it reflected successfully, establishing my initial foothold.

2. Unauthenticated Reflected XSS (CWE-79) — Devcomm CMS

Building on the initial HTML injection, I confirmed the application failed to implement standard output encoding on the user-supplied pattern parameter.

Vector: Injecting standard HTML/JavaScript payloads directly into the search parameter reflected the payload unsanitized in the Document Object Model (DOM).
Proof of Concept (PoC): Navigating to https://koscierzyna.e-bip.eu/index.php?id=szukaj&pattern=<script>alert('Vulnerable_to_XSS')</script> resulted in immediate script execution.
Impact: Because the PHPSESSID cookie lacked the HttpOnly flag, this reflected XSS created a direct vector for the programmatic exfiltration of session tokens, leading to potential administrative account takeover.

Evidence: Unsanitized input executing within the browser context.

3. Database Information Exposure & Missing Rate Limiting — Devcomm CMS

Further probing revealed significant backend flaws. By intentionally breaking the template routing logic, I successfully induced a verbose exception.

Vector: Injecting a single quote (') into the id parameter caused the application to fail ungracefully.
Impact: This triggered a global memory dump directly to the browser (CWE-209). The stack trace leaked plaintext PostgreSQL database credentials, including the Database Name (testowybdb1), the Database Address (localhost), the internal port, and the Database User (testowyb).

Combined with a complete absence of rate limiting on the primary administrative login portal, these leaked details significantly lowered the barrier for credential stuffing and brute-force attacks.

Evidence: Verbose error handling leaking PostgreSQL database credentials. (Sensitive hashes and tokens redacted).

Database Credentials Leak in HTTP Response

Evidence: Raw HTTP response explicitly leaking the PostgreSQL database name, host, and user details in the source code.

4. API Over-fetching & GDPR Violation (CWE-200) — Sygnalista Module

The Sygnalista instances are designed for secure, anonymous whistleblowing. During the report submission process, users must check a compliance box explicitly acknowledging GDPR mandates and verifying that personal data will only be available to authorized entities. Paradoxically, the application fundamentally violates this directive via an API over-fetching flaw.

Evidence: The Sygnalista portal explicitly mandating GDPR compliance and promising strict data protection, directly contradicting the underlying API behavior.

Vector: Upon submitting a report, the user receives a tracking token. Entering this token at the status check portal prompts the backend to issue a POST request to the /notifications/view endpoint.
Impact: Intercepting this API response revealed the improper disclosure of the complete users array. This response leaked the full names, corporate email addresses, and system permissions of the internal compliance and audit team. Exposing the PII of personnel on a platform built for anonymity constitutes a severe privacy failure and a direct violation of the GDPR agreement presented to the user.

Evidence: API response unnecessarily exposing the first name, last name, and internal emails of compliance officers. (Identifying PII redacted).

The Disclosure & Remediation Process: 30 Emails and a Bureaucratic Loophole

The Coordinated Vulnerability Disclosure (CVD) process for this campaign highlights the complexities of enforcing vendor accountability and the loopholes within current CVE assignment rules.

I responsibly disclosed all findings to CERT.PL on April 7, 2026. What followed was a highly active 50-day coordination window characterized by vendor evasion, strict CNA policy interpretations, and over 30 email exchanges to push for remediation.

CERT.PL initially confirmed the vulnerabilities but stated that the Sygnalista module was a fully managed SaaS product, meaning no CVE would be assigned for the GDPR violation. Furthermore, they refused to assign a CVE for the Database Information Exposure, arguing that exposing the database name and user without the password was "not sufficient on its own to make an attack feasible," despite the total lack of rate limiting.

CERT.PL did, however, agree to process the Reflected XSS. On May 8, they officially reserved CVE-2026-8171 under my name. By May 18, they confirmed they were actively working with the vendor to set a publication date and draft the CVE entry.

Evidence: Official communication from CERT Polska reserving CVE-2026-8171 prior to the vendor's architectural migration.

Then, on May 25—after 47 days of coordination—CERT.PL abruptly withdrew the reserved CVE. During this 50-day window, I observed HTTP response headers indicating the 40+ domains had "Moved." Instead of taking a few minutes to implement proper output encoding to patch the vulnerable search parameters natively, the vendor aggressively prioritized migrating the vulnerable legacy sites to a cloud environment to claim SaaS status and legally dodge the CVE assignment.

When I requested a formal Letter of Appreciation or Hall of Fame acknowledgment to validate the reserved-then-withdrawn CVE, CERT.PL forwarded a message directly from the vendor. The vendor explicitly admitted that the vulnerabilities affected all previous versions of the system, but claimed they were now provided exclusively as SaaS. CERT.PL used this to defend their withdrawal, stating that reserving a CVE does not prevent its rejection if they determine it falls under SaaS CNA rules. Furthermore, they explicitly declined to provide a letter of appreciation, redirecting me back to the unresponsive vendor.

Evidence: CERT.PL confirming the vendor's SaaS claim affecting all previous versions, the rejection of the CVE, and their policy on appreciation letters.

I escalated the SaaS loophole dispute to the Root CNA (MITRE), who directed me to ENISA (the Root CNA for CERT.PL). Both ENISA and the vendor ignored the communications regarding the loophole.

Despite the bureaucratic friction and the loss of a public CVE identifier, the primary objective of ethical security research was achieved: the vendor was forced into action, and 40+ Polish government infrastructure portals are now permanently secure.

Disclosure Timeline

April 7, 2026: Comprehensive vulnerability report covering 40 domains submitted to CERT.PL.
Mid-April 2026: CERT.PL confirms vendor acknowledgment. Rejects CVEs for Sygnalista (SaaS rule) and Info Disclosure (policy interpretation).
May 8, 2026: CERT.PL officially reserves CVE-2026-8171 for the Reflected XSS and requests researcher credit details.
May 18, 2026: CERT.PL confirms they are preparing the CVE draft and coordinating a publication date.
May 25, 2026: CERT.PL withdraws CVE-2026-8171, citing the vendor's sudden claim that BIP CMS is distributed via a SaaS model.
Late May - June 2026: 30+ email exchanges completed. Escalation attempts made to MITRE and ENISA regarding the CVD loophole.
June 16, 2026: Final notice served. The infrastructure migration is confirmed complete, and the vulnerabilities are mitigated.
July 2026: Advisory published following the conclusion of the 90-day responsible disclosure window.

Conclusion

This engagement underscores the critical necessity of manual, adversarial vulnerability research. Automated security scanners frequently fail to identify chained logic flaws, API over-fetching hidden behind post-submission workflows, and missing rate limits.

Furthermore, this case highlights a significant flaw in the CVE tracking system: vendors can effectively erase their security failures from the public record by migrating vulnerable infrastructure to the cloud mid-disclosure. However, a researcher's true impact is not measured by CVE assignments, but by the real-world remediation of the critical systems they protect.