--- title: 'How I found a vulnerability in WP mail?' description: "I write about how I discovered a vulnerability in the Wirtualna Polska (WP) mail service, which allowed me to execute stored XSS in user session. I explain the technical details of the bug, how I exploited it, and the response from WP's security team." date: '2026-02-17' tags: ['security', 'vulnerability', 'wp', 'mail'] published: true --- About a week ago (report sent February 10, 2026), I found a stored XSS vulnerability in WP Mail and O2 Mail — both share the same web interface and infrastructure under Wirtualna Polska. The last public mention of an XSS bug in WP Mail was from 2012 on Niebezpiecznik, found by Jakub Zoczek (now at Securitum). The codebase looks completely different today — Chakra UI + Radix UI + React versus custom CSS and jQuery back then — so it was worth checking from scratch. ## Source maps Testing the frontend was significantly easier because of publicly available Webpack source maps. For an attacker, these are a gift: they allow full reconstruction of the original TypeScript source, including author comments, from minified JavaScript. In WP Mail's case, this made it straightforward to trace exactly where API values were being rendered in the DOM. ## The bug The root cause was a classic misuse of dangerouslySetInnerHTML in React — HTML content from the API rendered directly, with no sanitization step in between. Worth noting: even with sanitization in place, the default DOMPurify configuration without an explicit FORBID_TAGS list for: `iframe, object, embed` would still have let the payload through. The fix required both correct frontend sanitization and an updated tag-blocking policy. ## Stored XSS via signature endpoint The interesting part was persistence. A single POST request to /api/v1/signatures was enough to inject a malicious payload into a user's signature — the endpoint didn't verify the XSRF-TOKEN header (though SameSite=Lax on the session cookie limited external CSRF exposure). The payload used an `