Bump testcontainers from 0.27.3 to 0.28.0 - #481
Conversation
Bumps [testcontainers](https://github.com/testcontainers/testcontainers-rs) from 0.27.3 to 0.28.0. - [Release notes](https://github.com/testcontainers/testcontainers-rs/releases) - [Changelog](https://github.com/testcontainers/testcontainers-rs/blob/main/CHANGELOG.md) - [Commits](testcontainers/testcontainers-rs@0.27.3...0.28.0) --- updated-dependencies: - dependency-name: testcontainers dependency-version: 0.28.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
f9e29f3 to
eba6707
Compare
![semgrep-code-mongodb[bot]](https://avatars.githubusercontent.com/u/45120?s=60&v=4){kind=small}
| use aws_sdk_ec2::Client as Ec2Client; | ||
| use aws_sdk_ecr::Client as EcrClient; | ||
| use aws_sdk_iam::{Client as IamClient, error::SdkError}; | ||
| use aws_sdk_kms::Client as KmsClient; |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Rust KMS, HSM, or PKCS#11 provider used. Record provider, key identifier, key origin, storage, and access-control boundary.
To resolve this comment:
✨ Commit fix suggestion
- Confirm that
KmsClientis required. If the application does not call AWS KMS, removeuse aws_sdk_kms::Client as KmsClient;. - Record the KMS provider as AWS Key Management Service (AWS KMS) and document the AWS account and region used by the client.
- Record the exact key identifier used by each KMS operation, such as a key ARN or alias. Keep identifiers in configuration rather than hardcoding them in source code.
- Record the key origin and storage, including whether the key is AWS-owned, AWS-managed, customer-managed, or uses imported or external key material. Document that AWS KMS stores and protects the key material.
- Restrict the IAM role or user used by this client to only the required KMS actions, such as
kms:Encrypt,kms:Decrypt, orkms:GenerateDataKey, and limit each action to the required key ARN. - Review the KMS key policy and document the access-control boundary, including the AWS account, IAM principals, workload identity, and any VPC endpoint or organizational restrictions that control access.
- Load the key identifier and AWS configuration from approved environment variables or a secrets/configuration manager, for example
KMS_KEY_ARN, and reject startup when the required value is missing or points to an unexpected account or region.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by crypto-inventory-rust-key-management-provider-use.
🛟 Help? Slack #semgrep-help or go/semgrep-help.
Resolution Options:
- Fix the code
- Reply
/fp $reason(if security gap doesn’t exist) - Reply
/ar $reason(if gap is valid but intentional; add mitigations/monitoring) - Reply
/other $reason(e.g., test-only)
You can view more details about this finding in the Semgrep AppSec Platform.
| Client::builder() | ||
| .redirect(Policy::none()) | ||
| .danger_accept_invalid_certs(true) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
LAX_CLIENT disables TLS certificate verification, allowing man‑in‑the‑middle to intercept and alter HTTPS requests made via get_client(true). Any self‑signed or forged certificate will be accepted, exposing tokens and data.
More details about this
The LAX_CLIENT is built with danger_accept_invalid_certs(true), which disables TLS certificate verification for every request made through this client. Any HTTPS connection made via get_client(true) can silently accept self‑signed or forged certificates, enabling interception and tampering.
How this can be exploited
- Attacker on the same network runs a TLS‑terminating proxy with a bogus cert:
- Example:
mitmproxy -p 443(auto‑generates a self‑signed cert) oropenssl req -x509 -newkey rsa:2048 -keyout k.pem -out c.pem -days 1 -nodes && sudo openssl s_server -accept 443 -cert c.pem -key k.pem -www.
- Example:
- They redirect traffic for the target host to their machine (e.g., ARP/DNS spoofing so api.example.com → attacker IP).
- Your code calls
let client = get_client(true);and thenclient.get(Url::parse("https://api.example.com/user").unwrap()).... - Because LAX_CLIENT accepts any cert, the TLS handshake with the attacker’s fake server succeeds.
- The attacker reads sensitive headers (e.g., Authorization: Bearer ) and returns altered JSON, causing data theft or logic manipulation while appearing as a successful HTTPS request.
Affected code
- In the LAX_CLIENT static initializer:
Client::builder().redirect(Policy::none()).danger_accept_invalid_certs(true)makes all requests via LAX_CLIENT trust any certificate.
To resolve this comment:
✨ Commit fix suggestion
- Change
.danger_accept_invalid_certs(true)to.danger_accept_invalid_certs(false)in theLAX_CLIENTand any other client builders. - Ensure that the
.danger_accept_invalid_hostnames(true)call is not present, or is set tofalseif it is needed. - Only set these options to
trueif you have a strong justification (such as for local testing environments or explicit documentation that security is intentionally reduced).
Setting .danger_accept_invalid_certs(false) ensures that your HTTP client verifies server TLS certificates, preventing potential man-in-the-middle attacks.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by reqwest-accept-invalid.
🛟 Help? Slack #semgrep-help or go/semgrep-help.
Resolution Options:
- Fix the code
- Reply
/fp $reason(if security gap doesn’t exist) - Reply
/ar $reason(if gap is valid but intentional; add mitigations/monitoring) - Reply
/other $reason(e.g., test-only)
You can view more details about this finding in the Semgrep AppSec Platform.
| let lax = Client::builder() | ||
| .danger_accept_invalid_certs(true) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Client built with danger_accept_invalid_certs(true) skips TLS chain validation, enabling MITM with a self‑signed cert matching the hostname.
More details about this
The lax HTTP client is built with Client::builder().danger_accept_invalid_certs(true), which disables TLS certificate validation. Any HTTPS request made with this client will accept a self‑signed or forged certificate, allowing an active network attacker to intercept and alter traffic.
Concrete exploit tied to this code:
- Attacker generates a self‑signed cert whose CN/SAN = the target host (e.g., api.example.com) and sets up a Wi‑Fi hotspot/transparent proxy.
- Your code calls ValidationClients::new(...), creating lax with danger_accept_invalid_certs(true), and client_for_rule(...) returns &self.lax when global_mode is Off or Lax and a rule opts into lax.
- When the app sends requests via lax, it accepts the attacker’s self‑signed cert and establishes HTTPS anyway.
- The attacker reads/modifies requests and responses (e.g., steals Authorization headers, session cookies, or injects malicious data), since the chain is not verified.
This behavior enables man‑in‑the‑middle attacks wherever lax is selected, even if the hostname matches, because the certificate trust chain is not checked.
To resolve this comment:
✨ Commit fix suggestion
- Change the line
let lax = Client::builder().danger_accept_invalid_certs(true).timeout(timeout).build()?;tolet lax = Client::builder().danger_accept_invalid_certs(false).timeout(timeout).build()?;so that client does not accept invalid certificates. - Review the logic that makes use of the lax client to determine if it is strictly necessary to disable certificate validation for any use case. Only allow invalid certificates if there is no other option, and after a risk assessment.
- Alternatively, if you must allow invalid certs for legacy or specific non-production testing, document the usage clearly in code comments and ensure this mode cannot be used in production.
- Remove
.danger_accept_invalid_hostnames(true)or.danger_accept_invalid_certs(true)anywhere they are set totrue. Only set these totruewhen you fully understand and accept the risks.
Allowing invalid certificates exposes users to man-in-the-middle attacks, so this should be avoided unless absolutely necessary for testing in isolated, trusted environments.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by reqwest-accept-invalid.
🛟 Help? Slack #semgrep-help or go/semgrep-help.
Resolution Options:
- Fix the code
- Reply
/fp $reason(if security gap doesn’t exist) - Reply
/ar $reason(if gap is valid but intentional; add mitigations/monitoring) - Reply
/other $reason(e.g., test-only)
You can view more details about this finding in the Semgrep AppSec Platform.
|
Semgrep found 9
Rust TLS configuration operation. Record crypto provider, protocol versions, endpoint role, peer, trust source, and deployment scope. 🛟 Help? Slack #semgrep-help or go/semgrep-help. Resolution Options:
Semgrep found 40
Rust cryptographic, TLS, SSH, WireGuard, PKCS#11, or KMS crate used. Correlate with reachable operations before treating it as active use. 🛟 Help? Slack #semgrep-help or go/semgrep-help. Resolution Options:
Semgrep found 31
Rust cryptographic operation sha::clone. Record algorithm parameters, key size, nonce handling, inputs, and caller purpose. 🛟 Help? Slack #semgrep-help or go/semgrep-help. Resolution Options:
Semgrep found 8
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files. View Dataflow Graphflowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>src/scanner/docker.rs</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/mongodb/kingfisher/blob/eba670703587bb8e97fa0c16b506c027da071e90/src/scanner/docker.rs#L210 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 210] out_dir</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/mongodb/kingfisher/blob/eba670703587bb8e97fa0c16b506c027da071e90/src/scanner/docker.rs#L210 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 210] blob_path_from_digest</a>"]
v3["<a href=https://github.com/mongodb/kingfisher/blob/eba670703587bb8e97fa0c16b506c027da071e90/src/scanner/docker.rs#L167 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 167] out_dir</a>"]
v4["<a href=https://github.com/mongodb/kingfisher/blob/eba670703587bb8e97fa0c16b506c027da071e90/src/scanner/docker.rs#L210 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 210] path</a>"]
end
v2 --> v3
v3 --> v4
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/mongodb/kingfisher/blob/eba670703587bb8e97fa0c16b506c027da071e90/src/scanner/docker.rs#L215 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 215] &path</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
🛟 Help? Slack #semgrep-help or go/semgrep-help. Resolution Options:
|
eba6707 to
f9e29f3
Compare
1 participant
Bumps testcontainers from 0.27.3 to 0.28.0.
Release notes
Sourced from testcontainers's releases.
Changelog
Sourced from testcontainers's changelog.
Commits
59792c3chore: release v0.28.0 (#964)5331a2adocs(site): add missing languages and reorder docs navigation (#955)7d8f95aci(deps): bump actions/checkout from 6 to 7 (#953)936a3b6chore(deps): update docker-compose-types requirement from 0.23 to 0.24 (#951)7588345chore(deps)!: update bollard 0.20 to 0.21 (#943)b06dd31chore(deps): update russh requirement from 0.60.0 to 0.61.2 (#950)24027d4chore: bump testcontainers/sshd image from 1.3.0 to 1.4.0 (#952)3067fcdchore(deps): update parse-display requirement from 0.9.0 to 0.11.0 (#942)5632380chore(deps): update astral-tokio-tar from 0.6.0 to 0.6.1 (#940)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)