CVE-2026-121245
Race condition in Autofill in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to potentially obtain sensitive information via
CVSS
—
Sin CVSS
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 3 nov 2026 · Última mod.: 3 nov 2026 · CWE-367
Sin historial EPSS suficiente todavía.
Race condition in Autofill in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to potentially obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium)
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-121050——
———Race condition in Mobile in Google Chrome on on iOS prior to 157.0.8103.38 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)5hCVE-2026-1210488.8 ALT—
———Race condition in V8 in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)4hCVE-2026-88968——
———Claude Code is an agentic coding tool. Prior to 2.1.251, the Edit tool validates a target using pathname and symlink resolution that is not bound to the underlying directory inode or file descriptor. On macOS, attacker-controlled code running in the Bash sandbox can atomically replace an in-workspace parent directory with a symlink after validation, causing the unsandboxed Edit implementation to overwrite a user-writable file outside the workspace. Exploitation requires attacker-controlled code to run inside the sandbox, such as from a malicious repository or dependency script. This issue is fixed in version 2.1.251.4hCVE-2026-1199778.1 ALT48.7%
——15WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3. This is due to predictable, web-accessible staging paths used during full-package core upgrades. This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window.5hCVE-2026-1162506.5 MED0.7%
——0In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with check_access_permission() and then opened it by name. Several places opened it with a plain open() or handed the path to a utility that opened it later: the servers.json export and import and the import file listing, and the files given to pg_dump, pg_dumpall, pg_restore and psql by Backup, Restore and Import/Export Data. A symbolic link swapped in at the file or at any parent directory between the check and the open redirected the operation outside the storage directory, so a file could be written, overwritten or read, or loaded into a table, as the operating-system account running pgAdmin. A hard link to an outside file, which O_NOFOLLOW does not detect, and a FIFO, which could hang a request, had the same effect. CVE-2026-86861 fixed this for the File Manager's save_file; these were the remaining paths.
Exploitation requires creating such a link or FIFO inside the user's storage directory. pgAdmin offers no way to do so, and the per-user storage directories belong to the pgAdmin account, so this requires write access to the storage backend as a different operating-system user, for example a shared or network-mounted storage directory, and winning the race.
The fix opens each file by walking down from the storage directory one component at a time with O_NOFOLLOW, accepting only a regular file with one link, and passes the utilities the open descriptor (/dev/fd/N) on Linux. Error messages no longer include the server path.
This issue affects pgAdmin 4: before 9.19.1dCVE-2026-1162406.5 MED18.2%
——5In server mode pgAdmin 4 validates a path into the user's storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:
- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.
- Listing a folder decoded the path a second time after the check, so a folder named like an encoded "..", which a user can create, listed any directory on the host.
- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user's storage directory name is a prefix of another's, another user's files could be read, deleted or moved; download also checked the path appended to itself.
- Creating a folder could create one in another user's directory.
The fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.
This issue affects pgAdmin 4: before 9.19.1d