| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Home-Gallery.org is a self-hosted open-source web gallery to browse personal photos and videos. In 1.15.0 and earlier, the default setup of home-gallery is vulnerable to DNS rebinding. Home-gallery is set up without TLS and user authentication by default, leaving it vulnerable to DNS rebinding. In this attack, an attacker will ask a user to visit their website. The attacker website will then change the DNS records of their domain from their IP address to the internal IP address of the home-gallery instance. To tell which IP addresses are valid, we can rebind a subdomain to each IP address we want to check, and see if there is a response. Once potential candidates have been found, the attacker can launch the attack by reading the response of the web server after the IP address has changed. When the attacker domain is fetched, the response will be from the home-gallery instance, not the attacker website, because the IP address has been changed. Due to a lack of authentication, home-gallery photos can then be extracted by the attacker website. |
| sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a validly-signed but "mismatched" bundle is presented as proof of inclusion into a transparency log. This bug impacts clients using any variation of KeylessVerifier.verify(). The verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby "verifying" a bundle without any proof the signing event was logged. This allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor's log monitors. The signer's identity will still be available to the verifier. The signature on the bundle must still be on the correct artifact for the verifier to pass. sigstore-gradle-plugin and sigstore-maven-plugin are not affected by this as they only provide signing functionality. This issue has been patched in v1.1.0 release with PR #856. All users are advised to upgrade. There are no known workarounds for this vulnerability. |
| quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2. |
| libosdp is an implementation of IEC 60839-11-5 OSDP (Open Supervised Device Protocol) and provides a C library with support for C++, Rust and Python3. In affected versions an unexpected `REPLY_CCRYPT` or `REPLY_RMAC_I` may be introduced into an active stream when they should not be. Once RMAC_I message can be sent during a session, attacker with MITM access to the communication may intercept the original RMAC_I reply and save it. While the session continues, the attacker will record all of the replies and save them, till capturing the message to be replied (can be detected by ID, length or time based on inspection of visual activity next to the reader) Once attacker captures a session with the message to be replayed, he stops resetting the connection and waits for signal to perform the replay to of the PD to CP message (ex: by signaling remotely to the MIMT device or setting a specific timing). In order to replay, the attacker will craft a specific RMAC_I message in the proper seq of the execution, which will result in reverting the RMAC to the beginning of the session. At that phase - attacker can replay all the messages from the beginning of the session. This issue has been addressed in commit `298576d9` which is included in release version 3.0.0. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Stirling-PDF is a locally hosted web application that allows you to perform various operations on PDF files. In affected versions the Merge functionality takes untrusted user input (file name) and uses it directly in the creation of HTML pages allowing any unauthenticated to execute JavaScript code in the context of the user. The issue stems to the code starting at `Line 24` in `src/main/resources/static/js/merge.js`. The file name is directly being input into InnerHTML with no sanitization on the file name, allowing a malicious user to be able to upload files with names containing HTML tags. As HTML tags can include JavaScript code, this can be used to execute JavaScript code in the context of the user. This is a self-injection style attack and relies on a user uploading the malicious file themselves and it impact only them, not other users. A user might be social engineered into running this to launch a phishing attack. Nevertheless, this breaks the expected security restrictions in place by the application. This issue has been addressed in version 0.32.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Orchid is a @laravel package that allows for rapid application development of back-office applications, admin/user panels, and dashboards. This vulnerability is a method exposure issue (CWE-749: Exposed Dangerous Method or Function) in the Orchid Platform’s asynchronous modal functionality, affecting users of Orchid Platform version 8 through 14.42.x. Attackers could exploit this vulnerability to call arbitrary methods within the `Screen` class, leading to potential brute force of database tables, validation checks against user credentials, and disclosure of the server’s real IP address. The issue has been patched in the latest release, version 14.43.0, released on November 6, 2024. Users should upgrade to version 14.43.0 or later to address this vulnerability. If upgrading to version 14.43.0 is not immediately possible, users can mitigate the vulnerability by implementing middleware to intercept and validate requests to asynchronous modal endpoints, allowing only approved methods and parameters. |
| Password Pusher is an open source application to communicate sensitive information over the web. A cross-site scripting (XSS) vulnerability was identified in the PasswordPusher application, affecting versions `v1.41.1` through and including `v.1.48.0`. The issue arises from an un-sanitized parameter which could allow attackers to inject malicious JavaScript into the application. Users who self-host and have the login system enabled are affected. Exploitation of this vulnerability could expose user data, access to user sessions or take unintended actions on behalf of users. To exploit this vulnerability, an attacker would need to convince a user to click a malicious account confirmation link. It is highly recommended to update to version `v1.48.1` or later to mitigate this risk. There are no known workarounds for this vulnerability.
### Solution
Update to version `v1.48.1` or later where input sanitization has been applied to the account confirmation process. If updating is not immediately possible, |
| Filament is a collection of full-stack components for accelerated Laravel development. All Filament features that interact with storage use the `default_filesystem_disk` config option. This allows the user to easily swap their storage driver to something production-ready like `s3` when deploying their app, without having to touch multiple configuration options and potentially forgetting about some. The default disk is set to `public` when you first install Filament, since this allows users to quickly get started developing with a functional disk that allows features such as file upload previews locally without the need to set up an S3 disk with temporary URL support. However, some features of Filament such as exports also rely on storage, and the files that are stored contain data that should often not be public. This is not an issue for the many deployed applications, since many use a secure default disk such as S3 in production. However, [CWE-1188](https://cwe.mitre.org/data/definitions/1188.html) suggests that having the `public` disk as the default disk in Filament is a security vulnerability itself. As such, we have implemented a measure to protect users whereby if the `public` disk is set as the default disk, the exports feature will automatically swap it out for the `local` disk, if that exists. Users who set the default disk to `local` or `s3` already are not affected. If a user wants to continue to use the `public` disk for exports, they can by setting the export disk deliberately. This change has been included in the 3.2.123 release and all users who use the `public` disk are advised to upgrade. |
| Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder. |
| golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above. |
| Refit is an automatic type-safe REST library for .NET Core, Xamarin and .NET The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection. The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method. This method does not check for CRLF characters in the header value. This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests. If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery. Strictly speaking this is a potential vulnerability in applications using Refit and not in Refit itself. This issue has been addressed in release versions 7.2.22 and 8.0.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux. The Git credential protocol is text-based over standard input/output, and consists of a series of lines of key-value pairs in the format `key=value`. Git's documentation restricts the use of the NUL (`\0`) character and newlines to form part of the keys or values. When Git reads from standard input, it considers both LF and CRLF as newline characters for the credential protocol by virtue of calling `strbuf_getline` that calls to `strbuf_getdelim_strip_crlf`. Git also validates that a newline is not present in the value by checking for the presence of the line-feed character (LF, `\n`), and errors if this is the case. This captures both LF and CRLF-type newlines. Git Credential Manager uses the .NET standard library `StreamReader` class to read the standard input stream line-by-line and parse the `key=value` credential protocol format. The implementation of the `ReadLineAsync` method considers LF, CRLF, and CR as valid line endings. This is means that .NET considers a single CR as a valid newline character, whereas Git does not. This mismatch of newline treatment between Git and GCM means that an attacker can craft a malicious remote URL. When a user clones or otherwise interacts with a malicious repository that requires authentication, the attacker can capture credentials for another Git remote. The attack is also heightened when cloning from repositories with submodules when using the `--recursive` clone option as the user is not able to inspect the submodule remote URLs beforehand. This issue has been patched in version 2.6.1 and all users are advised to upgrade. Users unable to upgrade should only interact with trusted remote repositories, and not clone with `--recursive` to allow inspection of any submodule URLs before cloning those submodules. |
| AshPostgres is the PostgreSQL data layer for Ash Framework. Starting in version 2.0.0 and prior to version 2.4.10, in certain very specific situations, it was possible for the policies of an update action to be skipped. This occurred only on "empty" update actions (no changing fields), and would allow their hooks (side effects) to be performed when they should not have been. Note that this does not allow reading new data that the user should not have had access to, only triggering a side effect a user should not have been able to trigger.
To be vulnerable, an affected user must have an update action that is on a resource with no attributes containing an "update default" (updated_at timestamp, for example); can be performed atomically; does not have `require_atomic? false`; has at least one authorizer (typically `Ash.Policy.Authorizer`); and has at least one `change` (on the resource's `changes` block or in the action itself). This is where the side-effects would be performed when they should not have been.
This problem has been patched in `2.4.10` of `ash_postgres`. Several workarounds are available. Potentially affected users may determine that none of their actions are vulnerable using a script the maintainers provide in the GitHub Security Advisory, add `require_atomic? false` to any potentially affected update action, replace any usage of `Ash.update` with `Ash.bulk_update` for an affected action, and/or add an update timestamp to their action. |
| Misskey is an open source, federated social media platform. In affected versions FileServerService (media proxy) in github.com/misskey-dev/misskey 2024.10.1 or earlier did not detect proxy loops, which allows remote actors to execute a self-propagating reflected/amplified distributed denial-of-service via a maliciously crafted note. FileServerService.prototype.proxyHandler did not check incoming requests are not coming from another proxy server. An attacker can execute an amplified denial-of-service by sending a nested proxy request to the server and end the request with a malicious redirect back to another nested proxy request.
Leading to unbounded recursion until the original request is timed out. This issue has been addressed in version 2024.11.0-alpha.3. Users are advised to upgrade. Users unable to upgrade may configure the reverse proxy to block requests to the proxy with an empty User-Agent header or one containing Misskey/. An attacker can not effectively modify the User-Agent header without making another request to the server. |
| ACON is a widely-used library of tools for machine learning that focuses on adaptive correlation optimization. A potential vulnerability has been identified in the input validation process, which could lead to arbitrary code execution if exploited. This issue could allow an attacker to submit malicious input data, bypassing input validation, resulting in remote code execution in certain machine learning applications using the ACON library. All users utilizing ACON’s input-handling functions are potentially at risk. Specifically, machine learning models or applications that ingest user-generated data without proper sanitization are the most vulnerable. Users running ACON on production servers are at heightened risk, as the vulnerability could be exploited remotely. As of time of publication, it is unclear whether a fix is available. |
| secp256k1-node is a Node.js binding for an Optimized C library for EC operations on curve secp256k1. In `elliptic`-based version, `loadUncompressedPublicKey` has a check that the public key is on the curve. Prior to versions 5.0.1, 4.0.4, and 3.8.1, however, `loadCompressedPublicKey` is missing that check. That allows the attacker to use public keys on low-cardinality curves to extract enough information to fully restore the private key from as little as 11 ECDH sessions, and very cheaply on compute power. Other operations on public keys are also affected, including e.g. `publicKeyVerify()` incorrectly returning `true` on those invalid keys, and e.g. `publicKeyTweakMul()` also returning predictable outcomes allowing to restore the tweak. Versions 5.0.1, 4.0.4, and 3.8.1 contain a fix for the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to truncate first page in error path of f2fs_truncate()
syzbot reports a bug as below:
loop0: detected capacity change from 0 to 40427
F2FS-fs (loop0): Wrong SSA boundary, start(3584) end(4096) blocks(3072)
F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (loop0): invalid crc value
F2FS-fs (loop0): f2fs_convert_inline_folio: corrupted inline inode ino=3, i_addr[0]:0x1601, run fsck to fix.
------------[ cut here ]------------
kernel BUG at fs/inode.c:753!
RIP: 0010:clear_inode+0x169/0x190 fs/inode.c:753
Call Trace:
<TASK>
evict+0x504/0x9c0 fs/inode.c:810
f2fs_fill_super+0x5612/0x6fa0 fs/f2fs/super.c:5047
get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692
vfs_get_tree+0x8f/0x2b0 fs/super.c:1815
do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808
do_mount fs/namespace.c:4136 [inline]
__do_sys_mount fs/namespace.c:4347 [inline]
__se_sys_mount+0x317/0x410 fs/namespace.c:4324
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
During f2fs_evict_inode(), clear_inode() detects that we missed to truncate
all page cache before destorying inode, that is because in below path, we
will create page #0 in cache, but missed to drop it in error path, let's fix
it.
- evict
- f2fs_evict_inode
- f2fs_truncate
- f2fs_convert_inline_inode
- f2fs_grab_cache_folio
: create page #0 in cache
- f2fs_convert_inline_folio
: sanity check failed, return -EFSCORRUPTED
- clear_inode detects that inode->i_data.nrpages is not zero |
| Action Mailer is a framework for designing email service layers. Starting in version 3.0.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in the block_format helper in Action Mailer. Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. As a workaround, users can avoid calling the `block_format` helper or upgrade to Ruby 3.2. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected. |
| RDS Light is a simplified version of the Reflective Dialogue System (RDS), a self-reflecting AI framework. Versions prior to 1.1.0 contain a vulnerability that involves a lack of input validation within the RDS AI framework, specifically within the user input handling code in the main module (`main.py`). This leaves the framework open to injection attacks and potential memory tampering. Any user or external actor providing input to the system could exploit this vulnerability to inject malicious commands, corrupt stored data, or affect API calls. This is particularly critical for users employing RDS AI in production environments where it interacts with sensitive systems, performs dynamic memory caching, or retrieves user-specific data for analysis. Impacted areas include developers using the RDS AI system as a backend for AI-driven applications and systems running RDS AI that may be exposed to untrusted environments or receive unverified user inputs. The vulnerability has been patched in version 1.1.0 of the RDS AI framework. All user inputs are now sanitized and validated against a set of rules designed to mitigate malicious content. Users should upgrade to version 1.1.0 or higher and ensure all dependencies are updated to their latest versions. For users unable to upgrade to the patched version, a workaround can be implemented. The user implementing the workaround should implement custom validation checks for user inputs to filter out unsafe characters and patterns (e.g., SQL injection attempts, script injections) and limit or remove features that allow user input until the system can be patched. |
| Starlette is an Asynchronous Server Gateway Interface (ASGI) framework/toolkit. Prior to version 0.40.0, Starlette treats `multipart/form-data` parts without a `filename` as text form fields and buffers those in byte strings with no size limit. This allows an attacker to upload arbitrary large form fields and cause Starlette to both slow down significantly due to excessive memory allocations and copy operations, and also consume more and more memory until the server starts swapping and grinds to a halt, or the OS terminates the server process with an OOM error. Uploading multiple such requests in parallel may be enough to render a service practically unusable, even if reasonable request size limits are enforced by a reverse proxy in front of Starlette. This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) accepting form requests. Verison 0.40.0 fixes this issue. |
