Tale Of Forgotten Disclosure

This presentation by Anant Shrivastava at Null Meet Bangalore chronicles the real-world case study of a DOM-based Cross-Site Scripting (XSS) vulnerability in the jQuery prettyPhoto library — a widely-used JavaScript lightbox plugin embedded in dozens of WordPress plugins and countless websites. The talk traces the full disclosure timeline from initial discovery through the frustrating process of getting the vulnerability patched, and extracts critical lessons about dependency management, responsible disclosure, and the risks of using components with known vulnerabilities (OWASP A9).

Key Topics Covered

• The Vulnerability Scenario: A vulnerability existed in code last updated in March 2013, was publicly disclosed in August 2014, and had an unmerged pull request fix from January 2013. Despite a new release of the library after the pull request was submitted, the fix was not incorporated, leaving the vulnerability unpatched through May 2015.

• Technical Root Cause — DOM-Based XSS: The vulnerability was a JavaScript-based DOM-XSS found in the jquery.prettyphoto.js library. The getHashtag() function extracted and decoded URL fragment data using decodeURI() without sanitization, allowing injection of malicious payloads via the #prettyPhoto hash parameter. Versions 3.1.4 and 3.1.5 were confirmed vulnerable.

• Initial Discovery and Investigation: The issue was first identified through a compromised WordPress site using the “facebook-page-photo-gallery” plugin. Investigation traced the XSS to the prettyPhoto library bundled within the plugin. Removing the plugin fixed the immediate issue, but the underlying library vulnerability remained widespread.

• Disclosure Challenges: After reporting to the WordPress plugins team and receiving a response, the presenter attempted to contact the prettyPhoto library author directly. The effort required persistent outreach — spreading the word through multiple channels and contacts before finally getting some action from the maintainer.

• Scale of Impact: Research revealed 35 WordPress plugins bundling the vulnerable prettyPhoto library, accounting for over 2.88 million total downloads and approximately 337,780 active installations. Any website using jquery.prettyphoto.js versions 3.1.4 or 3.1.5 was vulnerable, extending the impact well beyond WordPress.

• The Fix and Its Delayed Adoption: The fix was straightforward — upgrade to prettyPhoto version 3.1.6. However, even after the fix was released, many plugins and sites remained unpatched, illustrating the systemic problem of transitive dependency updates in the web ecosystem.

• Lessons for Developers: Never ignore pull requests or security bug reports. Proactively test software for vulnerabilities. When a fix is released publicly, acknowledge the security issue transparently rather than burying it.

• Lessons for Developers, SysAdmins, and DevOps: Never ignore updates from shared libraries. Monitor how shared resources and dependencies are holding up. Actively track dependencies for known vulnerabilities rather than assuming they are safe.

• Dependency Tracking Limitations: The presentation acknowledged that at the time, comprehensive methods to track every third-party library for vulnerabilities were lacking. Manual tracking was still required, and existing tools (such as those shown in demos) were insufficient for full coverage.

• OWASP A9 — Using Components with Known Vulnerabilities: The entire case study maps directly to OWASP Top 10 2013 item A9, emphasizing that applications inheriting vulnerable third-party components are exposed to the same risks as if the vulnerability existed in their own code.

Actionable Takeaways

1. Audit all third-party JavaScript libraries and WordPress plugins in your projects for known vulnerabilities, paying special attention to bundled sub-dependencies like jQuery plugins that may not receive direct updates.
2. Implement a dependency monitoring process — use tools like Retire.js, npm audit, or similar scanners to detect outdated or vulnerable libraries, and establish a regular review cadence.
3. As a library maintainer, treat security-related pull requests and bug reports with urgency; delaying fixes amplifies the blast radius across all downstream consumers.
4. When deploying WordPress or similar CMS platforms, evaluate plugins not only for functionality but for the quality and currency of their bundled third-party libraries.
5. Adopt a defense-in-depth approach: even if upstream dependencies are slow to patch, apply mitigations such as Content Security Policy (CSP) headers and input sanitization to reduce exploitation risk.
6. For organizations, establish a formal vulnerability disclosure and response process so that reports from external researchers are triaged and acted upon promptly rather than ignored.