Checked as of 31 October 2026.

If your website runs a contact form, accepts file uploads, or processes PDF documents, part of that work happens inside third-party packages your developer installed once and may not have revisited since. This roundup covers three groups of notices. The GitHub-reviewed advisory records for all of them were published on 30 October 2026. The two hapi notices originate from upstream advisories published on 28 October. The sources for this article were checked on 31 October.

None of these notices describes remote code execution or data theft. Each describes a way that crafted input can keep a server or worker busy and make a site slow or unresponsive. Having the package installed is not proof of exposure. What matters is whether the vulnerable feature actually receives untrusted input on your deployed site. Your provider can verify that, and so can any owner or operator with access to the deployed code and configuration.

1. joi: email validation that accepts multiple addresses

What it is. joi is a widely used input validation library. CVE-2026-118772 (GHSA-4528-x5fx-h6hg) affects joi from 17.1.1 up to but not including 17.13.9, and from 18.0.0 up to but not including 18.3.1. The fixes are 17.13.9 and 18.3.1, both released on 28 October 2026. The legacy package @hapi/joi from 16.0.0 onward is listed as affected, and no fixed release is listed for it.

When it applies. Only to applications that pass untrusted text into an email rule configured to accept multiple addresses, without an effective length limit applied first. A slow pattern match can block the event loop and hurt availability.

Ask your provider to:

  • Confirm from the lockfile and the deployed dependency tree which joi branch is installed, and whether any schema uses the multiple-address email option on user-facing input.
  • Update to 17.13.9 or 18.3.1 on the matching branch, then rebuild and redeploy.
  • Treat legacy @hapi/joi as a migration task with tests. Do not assume the move to the current package is drop-in.
  • Read the original advisory before relying on a temporary length limit. It only helps when validation rejects early, and some configurations defeat it.

2. hapi multipart uploads: Content-Disposition parsing

What it is. CVE-2026-119202 (GHSA-8494-f6mr-cjpv) affects @hapi/content 6.0.2 and earlier, fixed in 6.0.3. The legacy package content from 3.0.6 through 4.0.6 is affected, with no fixed release listed for that branch. Release 6.0.3 dates from 21 October 2026, before the public advisory.

When it applies. Any code that parses an untrusted Content-Disposition header with this library. That includes hapi routes with multipart payloads enabled, where the header is parsed through @hapi/pez before your handler or validation runs. Whether an attacker can reach such a route, and whether login is required, depends on your route configuration. The outcome is CPU exhaustion, not code execution.

Ask your provider to:

  • Report the installed @hapi/content version, including as a transitive dependency, not only the top-level packages.
  • List the routes with multipart payloads enabled and who can reach them.
  • Update to 6.0.3 or a newer compatible patched version, rebuild and redeploy. For the legacy branch, plan a tested migration rather than assuming a drop-in swap.
  • Keep payload limits small. Smaller limits reduce the worst-case stall time and risk, but they are not a full fix, so the upgrade is still required.

3. pypdf: PDF processing workers

What it is. pypdf is a Python library, not a WordPress plugin and not Gotenberg. Seven notices, with GitHub-reviewed records published on 30 October, describe cases where a crafted PDF can hang a worker or consume excessive CPU or memory during specific operations: opening an incomplete file, walking the page tree, cloning dictionaries, reading page labels, or counting pages in an encrypted file. None claims code execution. Serving static PDFs from your site does not trigger any of them.

Affected before 6.21.4, fixed in 6.21.4:

Affected before 6.21.3, fixed in 6.21.3:

Upgrading to 6.21.4, released 28 October 2026, or a newer patched version covers both groups.

Ask your provider to:

  • Identify which worker actually parses, clones, counts or labels PDFs with pypdf, and the version installed inside that deployed worker, not on a developer machine.
  • Update, redeploy, then verify with a harmless normal upload and a full processing run.
  • Keep CPU, memory and time limits plus queue isolation on the worker as operational risk reduction. They do not replace the patch, and a generic file size cap does not fix all of these cases.

What to request, in one message

Send your provider a short request for four things: evidence of the deployed versions and whether each notice applies, an update plan with a date, a post-release test of normal forms, uploads and PDF processing, and monitoring of response latency, process restarts and queue depth for a few days afterward. Remediation means compatible dependency changes, an updated lockfile, a rebuild and a redeployment, verified on the actual worker, not a fresh download on someone’s laptop. Our guide on monitoring beyond uptime explains which signals show a slowdown before users complain, and the backup strategy rules cover having a tested restore point before any dependency change.

None of the sources checked for this article establishes exploitation in the wild, and we make no claim either way.