chore(deps): update github actions

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
actions/cache (changelog)	action	digest	cdf6c1f → 27d5ce7
actions/setup-dotnet (changelog)	action	digest	baa11fb → c2fa09f
aws-actions/configure-aws-credentials (changelog)	action	digest	8df5847 → ec61189
codacy/git-version	action	patch	2.8.6 → 2.8.7
docker/scout-action (changelog)	action	digest	f8c7768 → bacf462
dorny/test-reporter	action	pinDigest	→ 3eeb9fc
dorny/test-reporter	action	minor	v2.5.0 → v2.7.0
taiki-e/install-action (changelog)	action	digest	f8d25fb → cf525cb

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

codacy/git-version (codacy/git-version)

v2.8.7

Compare Source

dorny/test-reporter (dorny/test-reporter)

v2.7.0

Compare Source

What's Changed

• Feature: Add slug-prefix output for link anchors #​731
• Feature: Report jest-junit testsuite errors as failures #​155
• Security: Update dependencies to fix reported security vulnerabilities

Other Changes

• Bump eslint from 9.39.3 to 9.39.4 by @​dependabot[bot] in #​732
• Bump @​typescript-eslint/parser from 8.56.1 to 8.57.0 by @​dependabot[bot] in #​733
• Bump jest from 30.2.0 to 30.3.0 by @​dependabot[bot] in #​734
• Bump undici from 6.23.0 to 6.24.1 by @​dependabot[bot] in #​736
• Update flatted package to v3.4.1 to fix a vulnerability by @​jozefizso in #​739

New Contributors

• @​dt-thomas-durand made their first contribution in #​731
• @​johnbartholomew made their first contribution in #​155

Full Changelog: dorny/test-reporter@v2.6.0...v2.7.0

v2.6.0

Compare Source

We updated all dependency packages to latest versions to fix reported security vulnerabilities.

What's Changed

• Fix: For workflow_run events, resolve the commit of the check run from related pull request head commits first (matching workflow_run.head_branch, then first PR), and fall back to workflow_run.head_sha for non-PR runs #​673
• Change: The test-reporter action will listed all artifacts associated with the build run #​693
• Maintenance: Upgrade to ESLint v9 #​629

New Contributors

• @​azchohfi made their first contribution in #​673

Full Changelog: dorny/test-reporter@v2.5.0...v2.6.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

🔍 Vulnerabilities of dockerhubaneo/armonik_control:0.38.1-renovategithubactions.7.sha.b463691f

📦 Image Reference dockerhubaneo/armonik_control:0.38.1-renovategithubactions.7.sha.b463691f

digest	sha256:4763f87211779e47f6413c46be41088bd6d0412ba10220311e0305428399fb0a
vulnerabilities
platform	linux/amd64
size	74 MB
packages	121

OpenTelemetry.Exporter.OpenTelemetryProtocol 1.15.0 (nuget) pkg:nuget/OpenTelemetry.Exporter.OpenTelemetryProtocol@1.15.0 # Dockerfile (175:175) COPY --from=build /app/publish/submitter . Memory Allocation with Excessive Size Value Affected range >=1.13.1 <1.15.3 Fixed version 1.15.3 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.014% EPSS Percentile 3rd percentile Description Summary When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided grpc-status-details-bin trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, allowing excessive memory allocation and potential denial of service (DoS). Details #5980 introduced a retry path that parses grpc-status-details-bin to extract gRPC retry delay information for retryable responses. On that path: OtlpGrpcExportClient captures grpc-status-details-bin from retryable status responses (ResourceExhausted / Unavailable). OtlpRetry invokes GrpcStatusDeserializer.TryGetGrpcRetryDelay using this untrusted trailer value. GrpcStatusDeserializer.DecodeBytes decoded a protobuf varint length and allocated new byte[length] without validating the bounds against the remaining payload size. A malicious or compromised collector (or a MitM in weakly-protected deployments) could return a crafted grpc-status-details-bin payload that forces oversized allocation and memory exhaustion in the instrumented process. Impact If an OTLP/gRPC endpoint is attacker-controlled (or traffic is intercepted), a crafted retryable response can trigger large allocations during trailer parsing, which may exhaust memory and cause process instability/crash (availability impact / DoS). Mitigation The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs. Workarounds None known. Remediation #7064 updates GrpcStatusDeserializer to validate decoded length-delimited field sizes before allocation by ensuring the requested length is sane and does not exceed the remaining payload. This causes malformed or truncated grpc-status-details-bin payloads to fail safely instead of attempting unbounded allocation. Memory Allocation with Excessive Size Value Affected range >=1.13.1 <1.15.2 Fixed version 1.15.2 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.015% EPSS Percentile 3rd percentile Description Summary When exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response. Details open-telemetry/opentelemetry-dotnet#6564 introduced a change to read the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter for both gRPC and HTTP/protobuf. An unintended consequence of this change is that the response body is fully read into memory when received with no upper-bound. This vulnerability was surfaced during the investigation of GHSA-w8rr-5gcm-pp58. Impact If an application using the OTLP exporter is configured to use a back-end/collector endpoint that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response the application could have its memory exhausted and create a denial-of-service condition. Mitigation The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs. Workarounds None known. Remediation #7017 updates the OTLP exporter for both gRPC and HTTP to: Limit the number of bytes read from the response body in an error condition to 4MiB (see docs: add response size limitation open-telemetry/opentelemetry-proto#781); Only attempt to read the response body if OpenTelemetry error logging is enabled.

OpenTelemetry.Api 1.15.0 (nuget) pkg:nuget/OpenTelemetry.Api@1.15.0 # Dockerfile (175:175) COPY --from=build /app/publish/submitter . Memory Allocation with Excessive Size Value Affected range >=0.5.0-beta.2 <1.15.3 Fixed version 1.15.3 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L EPSS Score 0.021% EPSS Percentile 6th percentile Description Summary The implementation details of the baggage, B3 and Jaeger processing code in the OpenTelemetry.Api and OpenTelemetry.Extensions.Propagators NuGet packages can allocate excessive memory when parsing which could create a potential denial of service (DoS) in the consuming application. Details Exceeding Limits BaggagePropagator.Inject<T>() does not enforce the length limit of 8192 characters if the injected baggage contains only one item. This change was introduced by #1048. Excessive allocation The following methods eagerly allocate intermediate arrays before applying size limits. BaggagePropagator.Extract<T>() - this change was introduced by chore(deps): update dependency node to v18.20.8 #1048. BaggagePropagator.Inject<T>() - this change was introduced by chore(deps): update dependency node to v18.20.8 #1048. B3Propagator.Extract<T>() - this change was introduced by API v4 services implementation #533. B3Propagator.Extract<T>() - this change was introduced by #3244. JaegerPropagator.Extract<T>() - this change was introduced by #3309. Impact Excessively large propagation headers, particularly in degenerate/malformed cases that consist or large numbers of delimiter characters, can allocate excessive amounts of memory for intermediate storage of parsed content relative to the size of the original input. Mitigation HTTP servers often set maximum limits on the length of HTTP request headers, such as Internet Information Services (IIS) which sets a default limit of 16KB and nginx which sets a default limit of 8KB. Workarounds Possible workarounds include: Configuring appropriate HTTP request header limits. Disabling baggage and/or trace propagation. Remediation #7061 refactors the handling of baggage, B3 and Jaeger propagation headers to stop parsing eagerly when limits are exceeded and avoid allocating intermediate arrays.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud