In the Linux kernel, the following vulnerability has been resolved:

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctpprocessasconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctprcv()). For an ASCONF located through its Address Parameter by sctprcvasconflookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.

sctpprocessasconfparam() rejects a DEL-IP for the packet source address (ADDIP D8, SCTPERRORDELSRCIP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctpassocrmpeer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctpassocsetprimary() and sctpassocdelnonprimarypeers(): setprimary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primarypath / activepath, and delnonprimarypeers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transportcount of 0 and primarypath/activepath pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.

Impact In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment. That environment typically holds secretkeybase and often credentials for external systems, which may in turn allow escalation to remote code execution or lateral movement to those systems.

Details libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as "unfuzzed", meaning they are unsafe for untrusted content, and several handle formats unrelated to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one.

We are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause disclosure of the contents of arbitrary files accessible on the filesystem of the targeted application. One specific attack chain has been reported to us (see "Disclosure" below), but we do not assume it is the only one that exists.

Affected applications An application is affected if it meets all of these requirements: - Uses libvips for Active Storage image processing. This is config.activestorage.variantprocessor = :vips, which loaddefaults 7.0 set and no later default has changed. - Allows image uploads from untrusted users.

Generating variants is not a separate requirement.

Mitigation - Upgrade to a fixed version of activestorage. - The minimum version of libvips must be upgraded to >= 8.13. - Change secretkeybase and change any secrets accessible in the application environment (see "Expire and change secrets" below)

Earlier versions of libvips (< 8.13) cannot disable unfuzzed operations at all, and Active Storage will raise an exception during boot in such an unsecurable environment.

Expire and change secrets

Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred. An affected application should treat every secret readable by the application process as potentially exposed and change it, including:

- secretkeybase - The master key, whether stored in config/master.key or supplied as RAILSMASTERKEY, along with everything in config/credentials.yml.enc that it decrypts - Credentials for the Active Storage service, such as S3, GCS, or Azure keys - Database credentials - Tokens and keys for any third-party service the application calls

Changing secretkeybase expires active sessions and requires users to log in again. Encrypted cookies, signed cookies, signed global IDs, and Active Storage URLs are also affected.

Rotation should only be used as an intermediate step if necessary. Do not retain an exposed secret as a fallback.

Workarounds If libvips < 8.13 is being used, there are no workarounds available other than removing the dependency on libvips from the application. Some applications may have ruby-vips declared as a dependency only for image analysis, and those applications may be able to simply remove ruby-vips from the Gemfile to remove libvips from the application. Applications that do not use Active Storage can remove ruby-vips from the Gemfile to avoid the boot-time checks.

If libvips >= 8.13 is present on the system, applications can disable the unfuzzed operations without upgrading Rails by setting the VIPSBLOCKUNTRUSTED environment variable, which libvips reads while initializing.

Applications also running ruby-vips >= 2.2.1 or later can instead call Vips.blockuntrusted(true) from an initializer.

Releases The fixed releases are available at the normal locations.

Versions affected

- activestorage < 7.2.3.2 - activestorage >= 8.0, < 8.0.5.1 - activestorage >= 8.1, < 8.1.3.1

Disclosure Technical details of the attack chain are intentionally omitted from this advisory. They would add nothing to an administrator's decision to upgrade, while making it substantially easier to attack applications that have not yet done so.

Details will be disclosed no later than 2026-08-28, via the Rails Security Announcements forum.

Credit This issue was responsibly reported by 0xacb, s3np41k1r1t0 and castilho from Ethiack, and RyotaK from GMO Flatt Security Inc..

References - libvips 8.13 release notes, blocking of unfuzzed loaders - W.A. Arbaugh, W.L. Fithen, and J. McHugh, "Windows of Vulnerability: A Case Study Analysis", IEEE Computer 33(12), December 2000 - https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve - https://blog.flatt.tech/entry/kindarails2shellrails

VMware vCenter contains a directory traversal vulnerability in the Syslog server. A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.

vBulletin 5.x through 5.7.5 and 6.x through 6.2.1 contains an eval injection vulnerability in the vB5TemplateRuntime::runMaths() method within the template runtime that allows unauthenticated remote attackers to execute arbitrary PHP code by supplying crafted input through the pagenav[pagenumber] parameter. Attackers can exploit the insufficiently restrictive regex filter by using phpfuck-style encoding with permitted characters to inject and execute arbitrary PHP code via the unauthenticated ajax/render template route without any authentication.

Apache Thrift: C++ ZLIB heap buffer overflow (write) in THeaderTransport::untransform()

Apache Thrift: cglib TLS Client Missing Hostname Verification

WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 is affected by a REST API batch endpoint route confusion issue which, combined with the authornotin WPQuery SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution.

WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the authornotin parameter of WPQuery, which could allow SQL Injection when a plugin or theme passes untrusted input to the parameter.