| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Early versions of Operator-SDK provided an insecure method to allow operator containers to run in environments that used a random UID. Operator-SDK before 0.15.2 provided a script, user_setup, which modifies the permissions of the /etc/passwd file to 664 during build time. Developers who used Operator-SDK before 0.15.2 to scaffold their operator may still be impacted by this if the insecure user_setup script is still being used to build new container images.
In affected images, the /etc/passwd file is created during build time with group-writable permissions and a group ownership of root (gid=0). An attacker who can execute commands within an affected container, even as a non-root user, may be able to leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container. |
| KDE messagelib before 25.11.90 ignores SSL errors for threatMatches:find in the Google Safe Browsing Lookup API (aka phishing API), which might allow spoofing of threat data. NOTE: this Lookup API is not contacted in the messagelib default configuration. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| ArcGIS Server version 11.5 and earlier on Windows and Linux does not properly validate uploaded files file, which allows remote attackers to upload arbitrary files. |
| ArcGIS Server version 11.5 and earlier on Windows and Linux does not properly validate uploaded files file, which allows remote attackers to upload arbitrary files. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| There is a stored cross site scripting issue in Esri ArcGIS Server 11.4 and earlier on Windows and Linux that in some configurations allows a remote unauthenticated attacker to store files that contain malicious code that may execute in the context of a victim’s browser. |
| A security vulnerability has been detected in actiontech sqle up to 4.2511.0. The impacted element is an unknown function of the file sqle/utils/jwt.go of the component JWT Secret Handler. The manipulation of the argument JWTSecretKey leads to use of hard-coded cryptographic key
. The attack is possible to be carried out remotely. The attack's complexity is rated as high. The exploitability is regarded as difficult. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report and is planning to fix this flaw in an upcoming release. |
| Gitea before 1.21.8 inadvertently discloses users' login times by allowing (for example) the lastlogintime explore/users sort order. |
| Gitea before 1.22.2 sometimes mishandles the propagation of token scope for access control within one of its own package registries. |
| In Gitea before 1.21.2, an anonymous user can visit a private user's project. |
| In Gitea before 1.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS. |
| A security vulnerability has been detected in code-projects Refugee Food Management System 1.0. This vulnerability affects unknown code of the file /home/editrefugee.php. Such manipulation of the argument a/b/c/sex/d/e/nationality_nid leads to sql injection. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. |
| Titra is open source project time tracking software. Prior to version 0.99.49, Titra allows any authenticated Admin user to modify the timeEntryRule in the database. The value is then passed to a NodeVM value to execute as code. Without sanitization, it leads to a Remote Code Execution. Version 0.99.49 fixes the issue. |
| RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine. In versions prior to 0.22.0, the use of an insecure key generation algorithm in the API key and beta (assistant/agent share auth) token generation process allows these tokens to be mutually derivable. Specifically, both tokens are generated using the same `URLSafeTimedSerializer` with predictable inputs, enabling an unauthorized user who obtains the shared assistant/agent URL to derive the personal API key. This grants them full control over the assistant/agent owner's account. Version 0.22.0 fixes the issue. |
| RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine. In versions prior to 0.23.0, a low-privileged authenticated user (normal login account) can execute arbitrary system commands on the server host process via the frontend Canvas CodeExec component, completely bypassing sandbox isolation. This occurs because untrusted data (stdout) is parsed using eval() with no filtering or sandboxing. The intended design was to "automatically convert string results into Python objects," but this effectively executes attacker-controlled code. Additional endpoints lack access control or contain inverted permission logic, significantly expanding the attack surface and enabling chained exploitation. Version 0.23.0 contains a patch for the issue. |
