[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"landing-trending":3,"cve-CVE-2025-52565":30,"landing-articles":93},{"count":4,"next":5,"previous":6,"results":7},266,"http:\u002F\u002Fweb:8606\u002Fapi\u002Ftrending_attacks\u002F?page=2&page_size=3&sorted_by=-published_at",null,[8,17,20],{"id":9,"title":10,"summary":11,"published_at":12,"severity":13,"vendor":14,"products":15},265,"Google Brotli decoder - Remote Code Execution via compressed requests (Exploitation Check)","This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it.\r\n\r\nWhy a second control\r\n\r\nCVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli (\"br\") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution.\r\n\r\nAny server that decompresses request bodies sent with \"Content-Encoding: br\" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library.\r\n\r\nThe flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support.\r\n\r\nWhat this control checks\r\n\r\nPatrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service.\r\n\r\nHow to read the result\r\n\r\nPotentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside.\r\n\r\nThis check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification.\r\n\r\nAffected and fixed versions\r\n\r\nGoogle Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution.\r\n\r\nRecommendations\r\n\r\nUpdate every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library.\r\n\r\nReduce the exposure until the update is deployed. Reject requests with \"Content-Encoding: br\" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as \"gzip, br\". On Envoy and Istio, disable request decompression for Brotli.\r\n\r\nReview outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.","2026-10-24T10:37:22.192753Z",4,"google",[16],"brotli",{"id":4,"title":10,"summary":18,"published_at":12,"severity":13,"vendor":14,"products":19},"This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it.\r\n\r\nWhy a second control\r\n\r\nCVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli (\"br\") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution.\r\n\r\nAny server that decompresses request bodies sent with \"Content-Encoding: br\" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library.\r\n\r\nThe flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support.\r\n\r\nWhat this control checks\r\n\r\nPatrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service.\r\n\r\nHow to read the result\r\n\r\nPotentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside.\r\n\r\nThis check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification.\r\n\r\nTwo situations are possible. When the decoding is done by your own application or reverse proxy, identify the component and update it. If an update is not possible right away, reject requests with \"Content-Encoding: br\" at the reverse proxy or WAF.\r\n\r\nWhen the asset is hosted on a managed platform or behind a CDN (for example Platform.sh, Upsun or Fastly), the decoding may be done by the provider's edge router, in front of your application. You cannot patch it yourself, but this router handles all the traffic of your site. Ask your provider to confirm that its edge components are patched against CVE-2026-111497. Assets hosted on a managed platform or behind a CDN carry the tag \"paas: platform.sh\" or \"cdn: fastly\" in the asset view: for these assets, the Brotli decoding is done by the provider's edge router, in front of your application, and only the provider can patch it.\r\n\r\nAffected and fixed versions\r\n\r\nGoogle Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution.\r\n\r\nRecommendations\r\n\r\nUpdate every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library.\r\n\r\nReduce the exposure until the update is deployed. Reject requests with \"Content-Encoding: br\" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as \"gzip, br\". On Envoy and Istio, disable request decompression for Brotli.\r\n\r\nContact your edge provider about the status of the pathing (Fastly \u002F Plateform.sh)\r\n\r\nReview outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.",[16],{"id":21,"title":22,"summary":23,"published_at":24,"severity":13,"vendor":25,"products":26},263,"Oracle Java SE JSSE - Improper Access Control & Unauthorized Data Access & Unauthorized Data Modification","Oracle Java SE is the Java runtime and development platform. Its JSSE (Java Secure Socket Extension) component provides TLS\u002FSSL for secure network communication. Oracle GraalVM is a JDK distribution based on the same platform.\r\n\r\nCVE-2026-91403\r\n\r\nA vulnerability in the JSSE component of Oracle Java SE, Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition can be exploited by an unauthenticated attacker with network access over multiple protocols. A successful attack can give unauthorized access to critical data and allow unauthorized creation, deletion or modification of data. It can also affect sandboxed Java Web Start applications and applets that run untrusted code. The record lists the weakness as CWE-284 (Improper Access Control) in the CISA ADP entry, while another database lists CWE-295. The record lists these affected versions:\r\n- Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1.\r\n- Oracle GraalVM for JDK: 17.0.21, 21.0.13.\r\n- Oracle GraalVM Enterprise Edition: 21.3.20.\r\n\r\nOracle published an out-of-cycle Security Alert on October 21, 2026. One secondary source says the fix makes Java distrust eight compromised intermediate CA certificates shipped with the JDK. The Oracle-focused sources do not confirm this root cause, so check it against the Oracle advisory. CISA ADP SSVC data shows Exploitation: none, Automatable: yes, Technical Impact: total. The CVE is not in the CISA KEV catalog as of October 22, 2026, and its EPSS score is below 1%.","2026-10-23T14:12:32.871954Z","Oracle",[27,28,29],"Oracle Java SE","Oracle GraalVM Enterprise Edition","Oracle GraalVM for JDK",{"id":31,"cve_id":32,"euvd_id":33,"summary":34,"published":35,"cvss_data":36,"is_remote":37,"cwes":38,"cpes":41,"technologies":62,"references":65,"score":77,"epss_score":78,"epss_percentile":79,"is_kev":37,"cisa_kev_date_added":6,"cisa_kev_due_date":6,"cisa_ssvc":80,"attack_mappings":90,"exploits":91},86109,"CVE-2025-52565","EUVD-2025-37944","runc container escape with malicious config due to \u002Fdev\u002Fconsole mount and related races\n\n### Impact ###\nThis attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `\u002Fdev\u002Fpts\u002F$n` to `\u002Fdev\u002Fconsole` as configured for all containers that allocate a console). \n\nIn runc version 1.0.0-rc3 and later, due to insufficient checks when bind-mounting `\u002Fdev\u002Fpts\u002F$n` to `\u002Fdev\u002Fconsole` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `\u002Fproc\u002Fsysrq-trigger` or `\u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern` (respectively). \n\nThe reason that the attacker can gain write access to these files is because the `\u002Fdev\u002Fconsole` bind-mount happens before `maskedPaths` and `readonlyPaths` are applied.\n\n#### Additional Findings ####\nWhile investigating this issue, runc discovered some other theoretical issues that may or may not be exploitable, as well as taking the opportunity to fix some fairly well-known issues related to consoles.\n\n##### Issue 1: Problematic Usage of `os.Create` #####\nGo provides an `os.Create` function for creating files, which older code in runc (dating back to the original `libcontainer` from the early 2010s) had a tendency to use fairly liberally. `os.Create` implies `O_CREAT|O_TRUNC` but by design it does not apply `O_NOFOLLOW` nor `O_EXCL`, meaning if the target is swapped with a malicious symlink runc can be tricked into truncating host files (which can lead to denial of service attacks, among other concerns). \n\nRunc conducted an audit of all `os.Create` usages in runc and found some suspicious usages related to device inodes, but based on runc's testing these were not exploitable in practice. Runc now has custom code lints to block any `os.Create` usage in runc, and plan to do a further audit of any other plain `os.*` operation usage throughout runc after this advisory becomes public. \n\nCVE-2024-45310 was a similar attack but without the `O_TRUNC` component (which resulted in a \"Low\" severity) -- a similar attack being exploitable would've been much more severe.\n\n##### Issue 2: Malicious `\u002Fdev\u002Fpts\u002F$n` Inode Attacks (`TIOCGPTPEER`) #####\nThe (very) classic API for constructing consoles involves first opening `\u002Fdev\u002Fptmx` for reading and writing. This allocates a new pseudo-terminal and the returned file descriptor is the \"master\" end (which is used by higher-level runtimes to do I\u002FO with the container). \n\nTraditionally, in order to get the \"slave\" end, you do `ioctl(ptm, TIOCGPTN)` to get the pseudo-terminal number and then open the file in `\u002Fdev\u002Fpts\u002F` with the corresponding base-10 decimal number of the number returned by `TIOCGPTN`. The naive way of doing this is vulnerable to very basic race attacks where `\u002Fdev\u002Fpts\u002F$n` is replaced with a different pseudo-terminal or other malicious file. \n\nIn order to provide a mechanism to mitigate this risk, Aleksa Sarai (@cyphar from SUSE) implemented `TIOCGPTPEER` back in 2017 to provide a race-free way of doing the last `TIOCGPTN` step by opening the peer end of the pseudo-terminal directly. However, at the time it was believed to be too impractical to implement this protection in runc due to its no-monitor-process architecture (unlike runtimes like LXC which made use of `TIOCGPTPEER` almost immediately). While working on this advisory, runc found a way to make `TIOCGPTN` usage on pre-4.13 kernels still safe against race attacks and so have implemented both `TIOCGPTPEER` support as well as safe `TIOCGPTN` support as a fallback. \n\nAnother possible target of attack would be replacing `\u002Fdev\u002Fptmx` or `\u002Fdev\u002Fpts\u002Fptmx` with a different inode and tricking runc into trying to operate on it. This is very similar to the core issue in CVE-2025-31133 and had a similar solution. \n\nRunc's analysis was that while this attack appears to be potentially problematic in theory, it seems unlikely to actually be exploitable due to how consoles are treated (runc tries to do several pseudo-terminal-specific `ioctl`s and will error out if they fail -- which happens for most other file types). In principle you could imagine a DoS attack using a disconnected NFS handle but it seems impractical to exploit. However, runc felt it prudent to include a solution (and this also provides a safe mechanism to get the source mount for the `\u002Fdev\u002Fconsole` bind-mount issue at the beginning of this advisory).\n\n### Patches ###\nThis advisory is being published as part of a set of three advisories:\n\n  * CVE-2025-31133\n  * CVE-2025-52881\n  * CVE-2025-52565\n\nThe patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:\n\n * db19bbed5348 (\"internal\u002Fsys: add VerifyInode helper\")\n * ff94f9991bd3 (\"*: switch to safer securejoin.Reopen\")\n * 531ef794e4ec (\"console: use TIOCGPTPEER when allocating peer PTY\")\n * 398955bccb7f (\"console: add fallback for pre-TIOCGPTPEER kernels\")\n * 9be1dbf4ac67 (\"console: avoid trivial symlink attacks for \u002Fdev\u002Fconsole\")\n * de87203e625c (\"console: verify \u002Fdev\u002Fpts\u002Fptmx before use\")\n * 01de9d65dc72 (\"rootfs: avoid using os.Create for new device inodes\")\n * aee7d3fe355d (\"ci: add lint to forbid the usage of os.Create\")\n\nrunc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per [runc's new release model](https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fblob\u002Fv1.4.0-rc.2\u002FRELEASES.md), runc 1.1.x and earlier are no longer supported and thus have not been patched.\n\n[CVE-2025-31133]: https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fsecurity\u002Fadvisories\u002FGHSA-9493-h29p-rfm2\n[CVE-2025-52565]: https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fsecurity\u002Fadvisories\u002FGHSA-qw9x-cqr3-wc7r\n[CVE-2025-52881]: https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fsecurity\u002Fadvisories\u002FGHSA-cgrx-mc8f-2prm\n[RELEASES.md]: https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fblob\u002Fv1.4.0-rc.2\u002FRELEASES.md\n\n### Mitigations ###\n* Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the `procfs` files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files. \n\nAn attacker would still be able to bind-mount host paths into the container but if the host uids and gids mapped into the container do not overlap with ordinary users on the host (which is the generally recommended configuration) then the attacker would likely not be able to read or write to most sensitive host files (depending on the Unix DAC permissions of the host files). Note that this is still technically more privilege than an unprivileged user on the host -- because the bind-mount is done by a privileged process, the attacker would be able to get access to directories whose parents may have denied search access (i.e., they may be able to access paths inside a `chmod 700` directory that would normally block them from resolving subpaths). \n\nRunc would also like to take this opportunity to re-iterate that runc **strongly** recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation *inside* the container -- most container runtimes apply a seccomp-bpf profile which blocks `unshare(CLONE_NEWUSER)` inside containers regardless of whether the container itself uses user namespaces. \n\nRootless containers can provide even more protection if your configuration can use them -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. \n\n * For non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling `noNewPrivileges` to disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use `ping` in your containers, there is a `net.ipv4.ping_group_range` sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries. \n * Do not run untrusted container images from unknown or unverified sources.\n * The default `containers-selinux` SELinux policy mitigates this issue, as (unlike CVE-2025-31133) the `\u002Fdev\u002Fconsole` bind-mount does not get relabeled and so the container process cannot write to the bind-mounted procfs file by default.\n\n   Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881.\n\n * The default AppArmor policy used by Docker and Podman does not mitigate this issue (as access to `\u002Fdev\u002Fconsole`) is usually permitted. Users could create a custom profile that blocks access to `\u002Fdev\u002Fconsole`, but such a profile might break regular containers.\n\n   Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so the mitigation provided with a custom profile is not that helpful when considered in combination with CVE-2025-52881.\n\n[CVE-2025-31133]: https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fsecurity\u002Fadvisories\u002FGHSA-9493-h29p-rfm2\n[CVE-2025-52881]: https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fsecurity\u002Fadvisories\u002FGHSA-cgrx-mc8f-2prm\n\n### Other Runtimes ###\nAs this vulnerability boils down to a fairly easy-to-make logic bug,runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.\n\nBased on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but [their security stance][lxc-security] is (understandably) that non-user-namespaced containers are fundamentally insecure by design.\n\n[lxc-security]: https:\u002F\u002Flinuxcontainers.org\u002Flxc\u002Fsecurity\u002F\n\n### Credits ###\n\nThanks to Lei Wang (@ssst0n3 from Huawei) and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering and reporting the main `\u002Fdev\u002Fconsole` bind-mount vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for discovering Issues 1 and 2 and the original research into these classes of issues several years ago.","2025-11-05T17:34:00Z",{},false,[39,40],"CWE-363","CWE-61",[42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61],"cpe:2.3:a:linuxfoundation:runc:1.0.0:rc90:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.4.0:rc2:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc8:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc7:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc4:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc92:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc93:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc5:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc3:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc95:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc9:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc94:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:*:*:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.4.0:rc1:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc6:*:*:*:*:*:*","cpe:2.3:a:linuxfoundation:runc:1.0.0:rc91:*:*:*:*:*:*","cpe:2.3:a:opencontainers:runc:*:*:*:*:*:*:*:*","cpe:2.3:a:opencontainers:runc:1.4.0-rc.2:*:*:*:*:*:*:*","cpe:2.3:a:opencontainers:runc:1.2.7:*:*:*:*:*:*:*","cpe:2.3:a:opencontainers:runc:1.3.2:*:*:*:*:*:*:*",[63,64],"Linuxfoundation Runc","Opencontainers Runc",[66,67,68,69,70,71,72,73,74,75,76],"https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002F01de9d65dc72f67b256ef03f9bfb795a2bf143b4","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002F398955bccb7f20565c224a3064d331c19e422398","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002F531ef794e4ecd628006a865ad334a048ee2b4b2e","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002F9be1dbf4ac67d9840a043ebd2df5c68f36705d1d","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002Faee7d3fe355dd02939d44155e308ea0052e0d53a","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002Fdb19bbed5348847da433faa9d69e9f90192bfa64","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002Fde87203e625cd7a27141fb5f2ad00a320c69c5e8","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fcommit\u002Fff94f9991bd32076c871ef0ad8bc1b763458e480","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc\u002Fsecurity\u002Fadvisories\u002FGHSA-qw9x-cqr3-wc7r","https:\u002F\u002Fnvd.nist.gov\u002Fvuln\u002Fdetail\u002FCVE-2025-52565","https:\u002F\u002Fgithub.com\u002Fopencontainers\u002Frunc",0,0.00811,0.56675,{"timestamp":81,"automatable":82,"tech_impact":83,"exploitation":84,"cisa_decision":85,"cisa_remediation_timeline":89},"2025-11-06T21:32:07.457681Z","no","partial","none",{"vector":86,"decision":87,"priority":88},"CISAv1\u002FE:N\u002FA:N\u002FT:P\u002FM:H\u002F2026-10-26T03:15:38.535349\u002F","track_star","medium","60D",[],[92],{"link":74},{"count":94,"next":95,"previous":6,"results":96},26,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&page_size=3&sorted_by=-published_at",[97,105,113],{"id":98,"title":99,"summary":100,"published_at":101,"type":102,"link":103,"image_url":104},30,"PHP2Shell: Two Critical RCE Flaws in PHP (CVSS 9.2)","Unauthenticated code execution demonstrated on WordPress, Drupal and Joomla, and reproduced in our lab. Patched versions and steps to take today.","2026-10-22T00:00:00Z","cve","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fphp2shell-2-critical-rce-flaws-php-cvss-9-2","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002Fc0615c4ee6-1792684469\u002Fphp2shell-2-critical-rce-flaws-php-cvss-9-2.png",{"id":106,"title":107,"summary":108,"published_at":109,"type":110,"link":111,"image_url":112},29,"Manage External Security Across All Your Entities","Centralize the management of entities, users and external security resources while maintaining strict data isolation with Patrowl.","2026-09-15T00:00:00Z","security tips","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fmulti-entity-external-security-how-structure-governance-group-level","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F8b2c0cc5eb-1789551467\u002Fvisu_1_multi_tenancy_dark_1x.webp",{"id":114,"title":115,"summary":116,"published_at":117,"type":118,"link":119,"image_url":120},28,"Will AI Become the Next Hacker? Bruce Schneier Answers at DEF CON 34","Tax law, finance, legislation: Bruce Schneier shows how AI could hack human rule systems just as easily as it hacks software.","2026-09-14T00:00:00Z","hacks","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fbruce-schneier-def-con-34","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F5c616d9db4-1789462598\u002Fai-hacker.en.png"]