Overview​

Two critical vulnerabilities have recently been disclosed in NGINX's ngx_http_rewrite_module. We have been actively monitoring both issues since disclosure. Our configuration is not susceptible to either vulnerability. As a precaution, we have updated our base NGINX images to the latest patched version.

The vulnerabilities​

NGINX Rift — CVE-2026-42945 (CVSS 9.2 Critical)​

Disclosed on 13 May 2026, NGINX Rift is a heap buffer overflow in NGINX's ngx_http_rewrite_module triggered when the rewrite, if, or set directive is used with an unnamed expression (such as $1 or $2) to replace strings after a question mark. A single crafted HTTP request from an unauthenticated remote attacker can crash the worker process (DoS) or, in some conditions, achieve remote code execution. The bug had been present in the codebase since NGINX 0.6.27 in 2008 and affects NGINX Open Source versions 0.6.27 through 1.30.0 and NGINX Plus R32 through R36.

NGINX PoolSlip — CVE-2026-9256 (CVSS 9.2 Critical)​

Disclosed on 22 May 2026, just nine days after Rift, PoolSlip is a second heap overflow in the same rewrite module. It is triggered when a rewrite directive uses a regex pattern with distinct, overlapping PCRE capture groups, such as ^/((.*))$ paired with a replacement string referencing multiple captures, like $1$2. The crafted request causes a controlled pointer "slip" across adjacent linked structures within the NGINX memory pool, allowing the attacker to overwrite cleanup handler pointers, again enabling DoS and potential RCE. Affected versions are NGINX Open Source 0.1.17 through 1.30.1 and 1.31.0.

Why our configuration is safe​

Both vulnerabilities require specific patterns in rewrite / set / if directives, unnamed capture groups for Rift, and overlapping PCRE capture groups with multi-capture backreferences for PoolSlip. Our base NGINX configuration does not use these patterns, so neither exploit is reachable against our deployed servers.

What we changed​

Out of an abundance of caution, we have updated our base NGINX images to the latest upstream release, which incorporates the patches for both CVE-2026-42945 and CVE-2026-9256. No action is required from customers; the updated images will roll out as part of the normal deployment cycle.

Link​

• CVE-2026-9256
• CVE-2026-42945

Overview​

Skpr now supports custom application metrics. Applications can expose metrics rooted in their own business logic, not just infrastructure signals like CPU and memory usage.

This lets you track what actually matters to your platform. For example: active user sessions, queue depth, or pieces of content published. You define the metrics in your application, and Skpr surfaces them alongside the platform's existing observability data.

Metrics are exposed in Prometheus format. Prometheus is a widely used open standard for collecting and querying time-series data. Any monitoring or alerting tool that reads this format can scrape, graph, and alert on your metrics with no custom integration work.

Link​

• How to enable application metrics for Drupal

Overview​

You can now view Content Delivery Network (CDN) upload and download metrics directly in the Skpr user interface.

These metrics show how much data your CDN is serving and receiving over time. That makes it easier to understand traffic patterns and spot unusual spikes.

Everything sits alongside your existing Skpr metrics, so you get a single view of how your application is performing.

Overview​

Nginx access logs now include a JA4 fingerprint for each request. JA4 is an open standard for fingerprinting TLS clients based on how they negotiate their connection, rather than what they claim to be.

This matters because details like the user agent can be faked. A JA4 fingerprint identifies the underlying client, so two requests from the same tool share a fingerprint even if one spoofs its user agent.

The fingerprint comes through from CloudFront and appears in the http_cloudfront_viewer_ja4_fingerprint field:

"http_cloudfront_viewer_ja4_fingerprint": "t13d1516h2_8daaf6152771_02713d6af862"

You can use it to spot bots, group related traffic, and investigate suspicious activity. It's especially useful for identifying automated clients during traffic spikes or denial-of-service attempts.

Overview​

In release v1.5.0, we've added a new command to the Skpr command-line interface (CLI): release pull.

This command pulls the packaged container images created by the skpr package command, so development teams can pull and debug the packaged application artefacts directly. To use it, run:

$ skpr release pull ENVIRONMENT

Link​

• v1.5.0

Overview​

With the release of Skpr v1.0 we have added first class support for Payload CMS.

Features:

• MongoDB support through AWS DocumentDB.
• Our CDN solution configured specifically to support Payload.
• CLI and Skpr UI support.
• Same development workflow as other project types.

Link​

• skpr/examples/payload

Overview​

We've implemented a new events system for the Skpr cluster.

Features:

• Fully supported through the CLI and Skpr UI.
• Events per project environment.
• Add @logStream = 'events' to your CloudWatch Logs Insights query for auditing your events.
• Event subscription system so you can do things like get a Slack notification when a shell session is started on production, or trigger a github action on a restore completion.
• Some example events:
  • Config has been set: my.config
  • Restore has completed: prod-123
  • Shell session has been created

Overview​

• Improved resolution of metrics through the Skpr UI from 5 minutes to 1 minute aggregation.
• Bugfix: Fixed an issue where CDN invalidation metrics weren't displaying.

Overview​

• Add @logStream = "waf" to your CloudWatch Logs Insights query to view log events where the WAF blocked a request.
• Logs are counted and rolled up by IP address.
• Provider information is also included in the log for enhanced debugging.

Overview​

Alpine 3.21 and above have changed the default mysql client to the mariadb client. As part of this change, the client now verifies the connection certificates by default.

When deploying to a preview environment or on a local development environment (depending on your configuration) mysql server is signed with a self-signed certificate causing the connection to fail. This change does not affect Skpr cluster environments.

Solution​

The solution is to disable the certificate verification using the MYSQL_ATTR_SSL_VERIFY_SERVER_CERT PDO setting for development (local and preview) environments. This alone will fix the web server connection issues, but does not fix the Drush CLI connection unless you're using version 13.7.2 and above.

if ($cert_path = $skpr->get('mysql.default.ca.crt')) {
  $databases['default']['default']['pdo'][\PDO::MYSQL_ATTR_SSL_CA] = $cert_path;
}
else {
  $databases['default']['default']['pdo'][\PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT] = FALSE;
}

See this change in context

We have worked with Drush to include a change that will disable the peer verification for the CLI when the above is set and this change was released in Drush 13.7.2. You will need to upgrade to Drush 13.7.2 to fix the issue for the CLI.

If for some reason you can't upgrade to Drush 13.7.2, please contact a Skpr Platform Team member as there are workarounds for connecting, but they are not as seamless as Drush sql:cli or similar.

Testing​

You can test your changes by switching to the latest image tag for your PHP containers (fpm and cli). These are located in .skpr/package/cli/Dockerfile and .skpr/package/fpm/Dockerfile.

Once the container is deployed you can confirm Alpine version with cat /etc/issue (3.21).

You can use drush version to check Drush version (13.7.2)

Finally a drush sql:cli command should work without certificate errors on a preview environment.

Timeline​

We will roll the alpine upgrade out to stable images on Monday, 30th March 2026.

Links​

• Code example in context
• Drush pull request