| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, logically adjacent BGP peer to cause Denial of Service (DoS).
On all Junos OS and Junos OS Evolved platforms, when BGP rib-sharding and update-threading are configured, and a BGP peer flap is done with specific timing, rpd crashes and restarts. Continuous peer flapping at specific time intervals will result in a sustained Denial of Service (DoS) condition.
This issue affects eBGP and iBGP, in both IPv4 and IPv6 implementations. This issue requires a remote attacker to have at least one established BGP session. The issue can occur with or without logical-systems enabled.
This issue affects:
Junos OS:
* All versions before 20.4R3-S8,
* 21.2 versions before 21.2R3-S6,
* 21.3 versions before 21.3R3-S5,
* 21.4 versions before 21.4R3-S4,
* 22.1 versions before 22.1R3-S3,
* 22.2 versions before 22.2R3-S1,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.
Junos OS Evolved:
* All versions before 21.2R3-S6-EVO,
* 21.3-EVO versions before 21.3R3-S5-EVO,
* 21.4-EVO versions before 21.4R3-S4-EVO,
* 22.1-EVO versions before 22.1R3-S3-EVO,
* 22.2-EVO versions before :22.2R3-S1-EVO,
* 22.3-EVO versions before 22.3R3-EVO,
* 22.4-EVO versions before 22.4R3-EVO. |
| Trix is a what-you-see-is-what-you-get rich text editor for everyday writing. Versions prior to 2.1.12 are vulnerable to cross-site scripting when pasting malicious code in the link field. An attacker could trick the user to copy&paste a malicious `javascript:` URL as a link that would execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed. Users should upgrade to Trix editor version 2.1.12 or later to receive a patch. In addition to upgrading, affected users can disallow browsers that don't support a Content Security Policy (CSP) as a workaround for this and other cross-site scripting vulnerabilities. Set CSP policies such as script-src 'self' to ensure that only scripts hosted on the same origin are executed, and explicitly prohibit inline scripts using script-src-elem. |
| GLPI is a free asset and IT management software package. In versions prior to 10.0.18, a malicious link can be crafted to perform a reflected XSS attack on the search page. If the anonymous ticket creation is enabled, this attack can be performed by an unauthenticated user. Version 10.0.18 contains a fix for the issue. |
| in OpenHarmony v5.0.2 and prior versions allow a local attacker cause DOS through out-of-bounds read. |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in asmedia allows Reflected XSS.This issue affects moseter: from n/a through 1.3.1. |
| in OpenHarmony v5.0.2 and prior versions allow a local attacker cause DOS through out-of-bounds read. |
| in OpenHarmony v5.0.2 and prior versions allow a local attacker cause DOS through out-of-bounds read. |
| Delta Electronics CNCSoft-G2 lacks proper validation of the length of user-supplied data prior to copying it to a fixed-length heap-based buffer. If a target visits a malicious page or opens a malicious file an attacker can leverage this vulnerability to execute code in the context of the current process. |
| A heap buffer overflow vulnerability in FFmpeg before commit 4bf784c allows attackers to trigger a memory corruption via supplying a crafted media file in avformat when processing tile grid group streams. This can lead to a Denial of Service (DoS). |
| A local privilege escalation vulnerability in SonicWall NetExtender Windows (32 and 64 bit) client which allows an attacker to trigger an arbitrary file deletion. |
| Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards. This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. This vulnerability is fixed in 1.0.14, 1.1.11, 1.2.11, and 1.3.4. |
| in OpenHarmony v5.0.2 and prior versions allow a local attacker cause DOS through buffer overflow. |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in fyrewurks Tiki Time allows Reflected XSS.This issue affects Tiki Time: from n/a through 1.3. |
| In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment. This vulnerability is patched in CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later.
For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first.
Environment variables are exposed only from workflow runs that satisfy all of the following conditions:
- Code scanning workflow configured to scan the Java/Kotlin languages.
- Running in a repository containing Kotlin source code.
- Running with debug artifacts enabled.
- Using CodeQL Action versions <= 3.28.2, and CodeQL CLI versions >= 2.9.2 (May 2022) and <= 2.20.2.
- The workflow run fails before the CodeQL database is finalized within the `github/codeql-action/analyze` step.
- Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo.
The `GITHUB_TOKEN` exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above:
- Using CodeQL Action versions >= 3.26.11 (October 2024) and <= 3.28.2, or >= 2.26.11 and < 3.
- Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server).
In rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory GHSA-gqh3-9prg-j95m for more details.
In CodeQL CLI versions >= 2.9.2 and <= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. This is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories.
On Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned.
The intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode.
Therefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the `GITHUB_TOKEN` and any user-configured secrets made available via environment variables.
The impact of the `GITHUB_TOKEN` leaked in this environment is limited:
- For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions >= 3.26.11 and <= 3.28.2, or >= 2.26.11 and < 3, which in turn use the `actions/artifacts v4` library, the debug artifact is uploaded before the workflow job completes. During this time the `GITHUB_TOKEN` is still valid, providing an opportunity for attackers to gain access to the repository.
- For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked `GITHUB_TOKEN` has been revoked and cannot be used to access the repository. |
| The HL7 FHIR IG publisher is a tool to take a set of inputs and create a standard FHIR IG. Prior to version 1.8.9, in CI contexts, the IG Publisher CLI uses git commands to determine the URL of the originating repo. If the repo was cloned, or otherwise set to use a repo that uses a username and credential based URL, the entire URL will be included in the built Implementation Guide, exposing username and credential. This does not impact users that clone public repos without credentials, such as those using the auto-ig-build continuous integration infrastructure. This problem has been patched in release 1.8.9. Some workarounds are available. Users should ensure the IG repo they are publishing does not have username or credentials included in the `origin` URL. Running the command `git remote origin url` should return a URL that contains no username, password, or token; or users should run the IG Publisher CLI with the `-repo` parameter and specify a URL that contains no username, password, or token. |
| CometBFT is a distributed, Byzantine fault-tolerant, deterministic state machine replication engine. In the `blocksync` protocol peers send their `base` and `latest` heights when they connect to a new node (`A`), which is syncing to the tip of a network. `base` acts as a lower ground and informs `A` that the peer only has blocks starting from height `base`. `latest` height informs `A` about the latest block in a network. Normally, nodes would only report increasing heights. If `B` fails to provide the latest block, `B` is removed and the `latest` height (target height) is recalculated based on other nodes `latest` heights. The existing code however doesn't check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X > Y`. `A` will be trying to catch up to 2000 indefinitely. This condition requires the introduction of malicious code in the full node first reporting some non-existing `latest` height, then reporting lower `latest` height and nodes which are syncing using `blocksync` protocol. This issue has been patched in versions 1.0.1 and 0.38.17 and all users are advised to upgrade. Operators may attempt to ban malicious peers from the network as a workaround. |
| CKAN is an open-source DMS (data management system) for powering data hubs and data portals. Using a specially crafted file, a user could potentially upload a file containing code that when executed could send arbitrary requests to the server. If that file was opened by an administrator, it could lead to escalation of privileges of the original submitter or other malicious actions. Users must have been registered to the site to exploit this vulnerability. This vulnerability has been fixed in CKAN 2.10.7 and 2.11.2. Users are advised to upgrade. On versions prior to CKAN 2.10.7 and 2.11.2, site maintainers can restrict the file types supported for uploading using the `ckan.upload.user.mimetypes` / `ckan.upload.user.types` and `ckan.upload.group.mimetypes` / `ckan.upload.group.types` config options. To entirely disable file uploads users can use: `ckan.upload.user.types = none` |
| Adobe Commerce versions 2.4.8-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 and earlier are affected by a Business Logic Error vulnerability that could result in a security feature bypass. An attacker could exploit this vulnerability to circumvent intended security mechanisms by manipulating the logic of the application's operations causing limited data modification. Exploitation of this issue does not require user interaction. |
| Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It's important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it's effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password. A patch for this issue has been applied to versions 4.38.19, and 4.39.0. Users are advised to upgrade. Users unable to upgrade should 1. Not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited. and 2. Disable the ability for users to login via an email address. |
| Develocity (formerly Gradle Enterprise) before 2024.3.1 allows an attacker who has network access to a Develocity server to obtain the hashed password of the system user. The hash algorithm used by Develocity was chosen according to best practices for password storage and provides some protection against brute-force attempts. The applicable severity of this vulnerability depends on whether a Develocity server is accessible by external or unauthorized users, and the complexity of the System User password. |
