Slides
Abstract
This presentation takes you to a tour of how not to handle vulnerability disclosures and how not to add a third party library in your system without keeping a track on the upstream.
This presentation takes you to a tour of how not to handle vulnerability disclosures and how not to add a third party library in your system without keeping a track on the upstream.
AI Generated Content Disclaimer
Note: This summary is AI-generated and may contain inaccuracies, errors, or omissions. If you spot any issues, please contact the site owner for corrections. Errors or omissions are unintended.
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).
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.
