| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Spring Tools for Eclipse stores the Spring Boot DevTools remote secret (spring.devtools.remote.secret) as a plain string attribute on the "Spring Boot DevTools Client" launch configuration. Eclipse persists launch configuration attributes as cleartext XML, either to workspace metadata or, if the user marks the configuration as a shared file, directly into the project tree where it can be committed to version control. This secret is the sole credential protecting the DevTools remote restart/reload endpoint, which accepts and executes arbitrary class bytes on the target application. Anyone able to read the .launch file (via filesystem access, a workspace backup, or a shared VCS repository) can extract the secret and use it to achieve remote code execution against the associated Spring Boot application.
Affected Spring Products and Versions:
Spring Tools for Eclipse: 5.2.0 and earlier |
| When enabling Spring Boot DevTools support for a remote application target (for example a Docker container or Cloud Foundry app) from the Spring Tools Boot Dashboard, Spring Tools generates a shared secret that authenticates DevTools remote-restart uploads to the deployed application. This secret was generated using a non-cryptographic pseudo-random number generator rather than a cryptographically secure source of randomness.
Affected Spring Products and Versions:
Spring Tools for Eclipse: 5.2.0 and earlier |
| The Boot Dashboard Docker integration in Spring Tools publishes container control ports on all of the host's network interfaces (0.0.0.0) rather than restricting them to loopback.
Affected Spring Products and Versions:
Spring Tools for Eclipse: 5.2.0 and earlier |
| A flaw in the PCP linux_sockets module exposes an unsecured internal connection.
An attacker with initial code execution can exploit this to escalate privileges and execute arbitrary commands as root. |
| Starting Spring Boot applications in the Spring Tools with the live information mode enabled makes the running application vulnerable against JMX-based remote code execution.
Affected Spring Products and Versions:
Spring Tools for Eclipse: 5.2.0 and earlier
Spring Tools for VSCode / Cursor / Theia: 2.2.0 and earlier |
| A command injection flaw in PCP's linux_sockets PMDA allows malicious shell metacharacters via the network.persocket.filter metric.
This failed validation lets attackers execute arbitrary commands as the PMDA user when metrics refresh. |
| Improper access control in the automation tests and workflows features in Devolutions PowerShell Universal 2026.2.2 and earlier allows an authenticated user with only the Reader role to execute automation tests and modify workflow properties via missing server-side authorization checks. |
| Improper control of generation of code ('Code Injection') in the variables feature in Devolutions PowerShell Universal 2026.2.2 and earlier allows an authenticated user with variable write permission to execute arbitrary PowerShell code via a crafted variable value that is not properly escaped when written to the variables configuration file. |
| Inappropriate implementation in File Input in Google Chrome on Linux prior to 151.0.7922.72 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in ANGLE in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Use after free in Views in Google Chrome on Mac prior to 151.0.7922.72 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in GPU in Google Chrome prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Insufficient validation of untrusted input in WebSockets in Google Chrome prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in Loader in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in Blink in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in Credential Management in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in Messages in Google Chrome on Android prior to 151.0.7922.72 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium) |
| Insufficient validation of untrusted input in Mobile in Google Chrome on Android prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in CSS in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to inject arbitrary scripts or HTML (UXSS) via a crafted HTML page. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential UAF in netfs_unlock_abandoned_read_pages()
netfs_unlock_abandoned_read_pages(rreq) accesses the index of the folios it
is wanting to unlock and compares that to rreq->no_unlock_folio so that it
doesn't unlock a folio being read for netfs_perform_write() or
netfs_write_begin().
However, given that netfs_unlock_abandoned_read_pages() is called _after_
NETFS_RREQ_IN_PROGRESS is cleared, the one folio that it's not allowed to
dereference is the one specified by ->no_unlock_folio as ownership
immediately reverts to the caller.
Fix this by storing the folio pointer instead and using that rather than
the index. Also fix netfs_unlock_read_folio() where the same applies. |
