ghsa

### Impact The PDF export uses a background job that runs on the server-side. Jobs like this have a status that is serialized in the permanent directory when the job is finished. The job status includes the job request. The PDF export job request is initialized, before the job starts, with some context information that is needed to replicate the HTTP request (used to trigger the export) in the background thread used to run the export job. This context information includes the cookies from the HTTP request that triggered the export. As a result, the user cookies (including the encrypted username and password) are stored in the permanent directory after the PDF export is finished. As the encryption key is stored in the same data directory (by default it is generated in ``data/configuration.properties``), this means that this job status contains the equivalent of the plain text password of the user who requested the PDF export. XWiki shouldn't store passwords in plain text, and it shoul...

### Impact Under certain conditions, back end users may be able to edit fields of pages and articles without having the necessary permissions. ### Patches Update to Contao 5.3.38 or 5.6.1. ### Workarounds None. ### For more information If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).

### Impact If a news feed contains protected news archives, their news items are not filtered and become publicly available in the RSS feed. ### Patches Update to Contao 5.3.38 or 5.6.1. ### Workarounds Do not add protected news archives to the news feed page. ### For more information If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).

### Impact Protected content elements that are rendered as fragments are indexed and become publicly available in the front end search. ### Patches Update to Contao 4.13.56, 5.3.38 or 5.6.1. ### Workarounds Disable the front end search. ### For more information If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).

### Impact The table access voter in the back end doesn't check if a user is allowed to access the corresponding module. ### Patches Update to Contao 5.3.38 or 5.6.1. ### Workarounds Do not rely solely on the voter and additionally check `USER_CAN_ACCESS_MODULE`. ### For more information If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).

### Summary There is a potential attack of arbitrary code injection vulnerability in `lychee-setup` of the composite action at *action.yml*. ### Details The GitHub Action variable `inputs.lycheeVersion` can be used to execute arbitrary code in the context of the action. ### PoC ```yaml - uses: lycheeverse/lychee@v2 with: lycheeVersion: $(printenv >> $GITHUB_STEP_SUMMARY && echo "v0.16.1") ``` The previous example will just print all the environment variables to the summary of the workflow, but an attacker could potentially use this vector to compromise the security of the target repository, even passing unnotice because the action will run normally. ### Impact Low

### Impact A vulnerability exists in NeuVector versions up to and including **5.4.5**, where a fixed string is used as the default password for the built-in `admin` account. If this password is not changed immediately after deployment, any workload with network access within the cluster could use the default credentials to obtain an authentication token. This token can then be used to perform any operation via NeuVector APIs. In earlier versions, NeuVector supports setting the default (bootstrap) password for the `admin` account using a Kubernetes Secret named `neuvector-bootstrap-secret`. This Secret must contain a key named `bootstrapPassword`. However, if NeuVector fails to retrieve this value, it falls back to the fixed default password. ### Patches This issue is resolved in NeuVector version **5.4.6** and later. For rolling upgrades, it's strongly recommended to change the default `admin` password to a secure one. Starting from version **5.4.6**, NeuVector introduces addition...

### Impact When a Java command with password parameters is executed and terminated by NeuVector for Process rule violation. For example, ``` java -cp /app ... Djavax.net.ssl.trustStorePassword=<Password> ``` The command with the password appears in the NeuVector security event. To prevent this, NeuVector uses the following default regular expression to detect and redact sensitive data from process commands: ``` (?i)(password|passwd|token) ``` Also, you can define custom patterns to redact by creating a Kubernetes ConfigMap. For example: ``` kubectl create configmap neuvector-custom-rules --from-file=secret-patterns.yaml -n neuvector ``` Sample `secret-patterns.yaml` content: ``` Pattern_list: - (?i)(pawd|pword) - (?i)(secret) ``` NeuVector uses the default and custom regex to decide whether the process command in a security event should be redacted. **Note:** If numerous regular expression (regex) patterns are configured in the Kubernetes ConfigMap for extended coverage ...

### Impact NeuVector stores user passwords and API keys using a simple, unsalted hash. This method is vulnerable to rainbow table attack (offline attack where hashes of known passwords are precomputed). NeuVector generates a cryptographically secure, random 16-character salt and uses it with the PBKDF2 algorithm to create the hash value for the following actions: - Creating a user - Updating a user’s password - Creating an API key **Note:** After upgrading to NeuVector 5.4.6, users must log in again so that NeuVector can regenerate the password hash. For API keys, you must send at least one request per API key to regenerate its hash value. ### Patches This issue is fixed in NeuVector version **5.4.6** and later. ### Workarounds There is no workaround. Upgrade to a patched version of NeuVector as soon as possible. ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/securit...

A vulnerability exists in the NodeRestriction admission controller in Kubernetes clusters where node users can delete their corresponding node object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection.