Skip to main content

Security policy

mod_pagespeed 2.1 processes untrusted content — HTML, CSS, JavaScript, and images from origin servers. We take this seriously.

Reporting vulnerabilities

If you've found a security vulnerability, please email security@modpagespeed.com with details. Do not open a public GitHub issue for security vulnerabilities.

What to include

  • • A description of the vulnerability and its potential impact.
  • • Steps to reproduce the issue.
  • • Affected versions, if known.
  • • Your assessment of severity and impact.

Our commitment

We acknowledge reports within 72 hours and follow a 90-day coordinated disclosure window: we aim to release a fix within 90 days of the initial report, after which the reporter may publish details. Critical vulnerabilities affecting production deployments jump the queue.

Safe harbor

We will not pursue legal action against security researchers who act in good faith. Good faith means: you report the vulnerability to us before disclosing publicly, you don't access or modify other users' data, and you don't degrade the service for others.

Scope

This security policy covers the mod_pagespeed 2.1 software (the module, the optimizer worker, and the cache layer) on Apache, nginx and IIS, and the modpagespeed.com website.

Security updates

Every security fix is listed on the release notes, with the release that carried it.

Evidence

Security disclosure

Report vulnerabilities to security@modpagespeed.com. Reports go by email; the repositories' SECURITY.md files state the same policy. See security.txt.

CVE history

Tracked in the release notes.

Dependency audits

The dependency gate blocks a change on any fixable vulnerability of medium severity or higher, checked against a pinned vulnerability database, and a daily scan against the live feed catches newly published ones.

SBOM

An SPDX 2.3 SBOM for the 2.1 line, with a VEX document, is published in the sbom/ directory of the source tree. The apt and yum repositories are GPG-signed and every release asset is listed in SHA256SUMS. Release SBOM and VEX documents are available to Priority and Enterprise subscribers on request. How to verify the signed packages is on the support page.

Architecture note

Both parts process untrusted content by design — they rewrite HTML, minify CSS and JavaScript, and transcode images from origins you configure. We take this attack surface seriously. Both parts of mod_pagespeed 2.1 build on a current toolchain and run with AddressSanitizer and UndefinedBehaviorSanitizer in CI, catching memory safety issues and undefined behavior before they reach production. The optimizer worker is written in C++23 with smart pointers and RAII throughout.

Threat model

mod_pagespeed processes untrusted images, CSS, JS, and HTML from origin servers. The worker process communicates only via a local Unix socket — it has no network access beyond the cache file and socket. All content parsing uses memory-safe patterns validated by continuous sanitizer testing (ASan, UBSan, TSan). No user data is transmitted externally.

Supply chain

All dependencies are pinned with SHA-256 checksums in the build configuration.

Search