CVE Vulnerability Catalog

In Tesseract prior to 5.5.4, WeightMatrix::DeSerialize trusts a mode byte from a traineddata LSTM network and calls WeightMatrix::DeSerializeOld when kDoubleFlag is clear. In default FAST_FLOAT builds, DeSerializeOld invokes ASSERT_HOST instead of returning an error, so loading a crafted model through TessBaseAPI::Init terminates the process and causes denial of service.

In Tesseract from 5.4.0 until 5.5.4, AppendLinePolygon in src/api/pagerenderer.cpp destroys the caller-owned right-to-left Pta accumulator while receiving it by value, leaving line_top_rtl_pts and line_bottom_rtl_pts dangling. On an upright Hebrew or Arabic page at the default PAGE XML level, POLYGONFLAG with a false skewed_flag enters the vulnerable calls, while LEVELFLAG greater than zero provides an alternative gate. The calls repeatedly read and free the stale object, causing a double free and use after free and allowing corrupted coordinates to reach RecalcPolygonline.

phoenix_html is vulnerable to cross-site scripting (XSS) due to improper neutralization of input during web page generation. The attributes_escape/1 function in lib/phoenix_html.ex escapes attribute values but not attribute names; a key such as 'x onmouseover' can end the attribute and start a new one, and atom keys are only dasherized, allowing any character including quotes and '>'. The issue affects versions from 1.0.0 before 3.3.5 and from 4.0.0 before 4.4.0.

SNARK Verifier is a generic (S)NARK verifier. Prior to 0.2.5, the Halo 2 aggregation circuit can mishandle proof points encoded as the point at infinity. EcPointLoader::multi_scalar_multiplication places a Value::Assigned(_) base paired with Value::Constant(ONE) into its unscaled variable-base list and passes it directly to sum_with_const. The default shim delegates to halo2-lib EccChip::sum, whose incomplete affine addition assumes nonidentity input points. A prover-controlled proof point encoded as (0, 0) can therefore enter the final aggregation sum through the scalar-one shortcut and affect the MSM or accumulator computation. Practical exploitability depends on the surrounding aggregation and final-decider checks; the advisory does not establish universal acceptance of invalid proofs. This issue is fixed in version 0.2.5.

OpenVM is a performant and modular zkVM framework built for customization and extensibility. Before 1.7.0 in the 1.x line and in affected 2.0 and 2.1 prereleases, OpenVmHalo2Verifier.verify accepts appExeCommit and appVmCommit as bytes32 values without checking that either is less than the BN254 scalar field modulus. Although public-value and proof-data lengths are checked, callers can provide non-canonical 256-bit encodings greater than or equal to that modulus at the Solidity wrapper boundary. Applications relying on the wrapper can therefore accept non-canonical app executable and app VM commitments, creating ambiguity between the supplied byte-level values and the field elements used by the verifier. This issue is fixed in versions 1.7.0, 2.0.0-rc.3 and 2.1.0-preview.

SNARK Verifier is a generic (S)NARK verifier. Prior to 0.2.5, KZG accumulator public-instance limbs are decoded without consistently enforcing canonical limb bounds before elliptic-curve coordinate reconstruction. PlonkProof::read selects scalars using accumulator_indices and passes them to AccumulatorEncoding::from_repr. For the EVM loader, LimbsEncoding::from_repr forwards them to EvmLoader::ec_point_from_limbs in snark-verifier/src/loader/evm/loader.rs, where shl and add reconstruct coordinates before validate_ec_point checks the resulting affine point rather than the original limb bounds. The related native path in snark-verifier/src/pcs/kzg/accumulator.rs can reach assertion- or unwrap-based decoding and panic instead of returning a verification error. This allows noncanonical encodings at the verifier boundary and can crash the native verifier. Standard SDK aggregation circuits are expected to constrain accumulator limbs before this boundary, which limits practical exploitability. This issue is fixed in version 0.2.5.

In HotCRP, the `cmt:USER` search term checks whether a comment is visible to the searching user but fails to check whether the commenter's identity should be visible. An authenticated user can therefore infer the author of an anonymous comment, compromising reviewer anonymity.

A vulnerability in the Arc time-series database allows cross-database authorization bypass through DuckDB I/O functions such as parquet_scan, glob, read_csv_auto, and others not covered by the denylist. The previous fix for CVE-2026-47735 did not block these aliases and functions, enabling unauthorized access to other databases' data, schemas, and statistics within the allowed root directory.

Maxthon Browser for Android before 7.5.8.103 contains an address bar spoofing vulnerability. A malicious page can render a counterfeit address bar showing a trusted domain by exploiting the lack of a persistent fullscreen notification, tricking users into disclosing credentials via phishing.

In Immich before 3.0.0, the GET /api/map/markers endpoint exposed to a view-only partner the GPS coordinates and existence of a sharer's archived photos or videos. The exposure is limited to location metadata and asset identifiers, as image bytes remain protected.

In Immich before 3.3.0, the unauthenticated machine-learning /predict endpoint accepted an options object without restricting security-sensitive parameters. An attacker with network access could set cache_dir to an arbitrary writable path, causing model downloads to write there and clear_cache() to recursively delete an attacker-selected directory via shutil.rmtree().

In pgAdmin 4, materialized view refresh passed the target database name to psql's --dbname argument unchanged. libpq treats a value containing "=" or a postgresql:// URI as a full connection string, allowing redirection to a chosen host and port and disclosure of the saved server password.

In pgAdmin 4, changing a user's password (by the user or an administrator) did not invalidate existing sessions. A session established before the change, e.g. on another device or by someone with the old password, stayed logged in until it expired.

In server mode pgAdmin 4 validated a user-supplied file path in the storage directory with check_access_permission() and then opened it by name using a plain open() or passed the path to utilities (pg_dump, pg_dumpall, pg_restore, psql) and to servers.json export/import and import file listing. Swapping in a symbolic or hard link or a FIFO between the check and the open redirected the operation outside the storage directory, allowing a file to be written, overwritten or read, or loaded into a table, as the pgAdmin operating-system account. This affects pgAdmin 4 before 9.19.

In pgAdmin 4 server mode, the server API create and update endpoints stored the "shared" flag and shared username, letting any user able to register a server share it with everyone. The servers.json import had a similar gap, as a non-administrator's "Shared" entries were removed only after validation.

In pgAdmin 4, the server password was written into pgAdmin's own process environment (as PGPASSWORD for the PSQL tool and under a per-process variable for a utility) and never removed. In server mode the environment is shared across all users' requests and copied into started processes, so another user could inherit the password and use it to connect.

In pgAdmin 4 server mode, a path validation flaw exists: check_access_permission() validated one path while callers acted on a differently constructed path, allowing files outside the user's storage directory to be read, written, deleted, or moved. Additionally, double-decoding of folder paths and missing separators when joining paths enabled access to other users' directories or the entire host filesystem. The issue affects pgAdmin 4 before 9.19 and does not affect desktop mode.

In Secret Server versions earlier than 12.3.1, the application did not always validate the PIN or biometric check when using a FIDO2-compliant device. This may allow bypassing the additional second-factor verification.

WIT SynApps Runtime through 1.4.11 contains a browser-mediated cross-origin request forgery vulnerability that allows attackers to supply an arbitrary target address during controller onboarding, causing the victim's browser to issue discovery requests to attacker-specified hosts. Attackers can leverage the victim's browser reachability to probe loopback addresses, local hostnames, or internal-only network hosts and initiate enrollment against REDY instances, crossing IT/OT segmentation boundaries.

WIT SynApps Runtime through 1.4.11 contains a pre-authentication reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject and execute arbitrary JavaScript by submitting a crafted LINK query parameter to the /System/Session-1 endpoint. Attackers can exploit this flaw to harvest credentials, manipulate the login flow, access browser-visible data, and perform same-origin requests to controller endpoints.