chore(deps): update pulumi to v3.261.0

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
pulumi	minor	3.260.0 → 3.261.0

---

Warning

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

---

Release Notes

pulumi/pulumi (pulumi)

v3.261.0

Compare Source

3.261.0 (2026-09-02)

Features

• [engine] Support state migration callbacks on resource registrations #​24328
• [cli/env] Add pulumi env setup {aws,azure,gcp} to configure cloud OIDC trust and create the ESC environments that use it #​23911

Bug Fixes

• [engine] Report a clear error instead of panicking when the stack's state contains a custom resource with no ID #​24438
• [cli] Show the agent account's claim URL instead of an inaccessible View Live link when running on ephemeral agent credentials #​24476
• [pcl] Fix a crash when binding a schema property with an integer constant value #​24480
• [cli/policy] Avoid hanging when policy pack fails to start up #​24492
• [pkg/testing] Fix ProgramTest for providers whose Go module or NuGet package has a double-digit major version #​24499
• [sdk] Fix serialization of secret unknowns in NodeJS, Python and PCL #​24500
• [engine] Ignore internal property keys (those starting with an underscore) when generating and checking update plans #​24532

Improvements

• [sdkgen] Generate precise Python output types for discriminated unions. An array of a union was typed Sequence[Any] and a scalar union Any, while the matching getters on the generated Args classes were already typed #​24485
• [sdk/python] Resolve a union value to its member by matching the value's wire shape, so unions whose members carry no constant properties serialize and translate with the right member's property names #​24484
• [sdkgen/python] Accept a generated output type wherever the classes-and-dicts input types accept its Args class or TypedDict, so a resource's output can be passed to another resource's input without a type error #​24507
• [engine] Send previously persisted outputs to a provider's Check on update, gated by a new sends_old_outputs_to_check handshake capability #​24524
• [sdk/python] Add helper methods to transform ResourceOptions to InvokeOptions #​24533

Miscellaneous

• [java] Upgrade java to v1.36.3 #​24509
• [yaml] Upgrade yaml to v1.38.5 #​24509
• [sdk/dotnet] Upgrade dotnet to v3.113.1 #​24512

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

• 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.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

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

---

This PR has been generated by Mend Renovate CLI.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/pulumi:3.261.0

📦 Image Reference ghcr.io/uniget-org/tools/pulumi:3.261.0

digest	sha256:912f4cc06db7ed5bb6ea7173bbded44d186e6abfd79824745c1e75e050233f4f
vulnerabilities
platform	linux/amd64
size	120 MB
packages	375

golang.org/x/mod 0.38.0 (golang) pkg:golang/golang.org/x/mod@0.38.0 Affected range <0.40.0 Fixed version 0.40.0 EPSS Score 0.107% EPSS Percentile 1st percentile Description A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log. All tiles are now correctly verified against their parents. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy Affected range <0.40.0 Fixed version 0.40.0 EPSS Score 0.298% EPSS Percentile 22nd percentile Description A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy

github.com/go-git/go-git/v6 6.0.0-alpha.4 (golang) pkg:golang/github.com/go-git/go-git@6.0.0-alpha.4#v6 Improper Link Resolution Before File Access ('Link Following') Affected range <=6.0.0-alpha.4 Fixed version 6.0.0-alpha.5 CVSS Score 7.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L EPSS Score 0.357% EPSS Percentile 29th percentile Description Impact A symlink traversal issue in go-git could allow worktree operations to modify files outside the intended worktree path. The worktreeFilesystem wrapper rejected dangerous path strings, including paths containing .git, parent-directory components, or control characters. However, it did not prevent filesystem operations from following symbolic links that were already present in the worktree. As a result, a path that is safe when evaluated as a string could still resolve into the repository's Git metadata directory. For example, if s is a symbolic link to .git, writing to s/config would modify .git/config. A symbolic link at the final path component could also be followed. For example, if s points directly to .git/config, opening s for writing with truncation could overwrite the repository configuration. Exploitation requires an attacker to be able to introduce or control a symbolic link in the worktree and cause the application to perform a write through that path. Applications using storage/memory for their Storer, or go-billy/memfs for their Worktree, are not affected by this vulnerability. Patches The issue has been addressed by making the worktree filesystem wrapper a symlink-safe boundary. Worktree operations now reject paths where an existing symbolic link in any path component could cause the operation to escape the intended worktree location, including symbolic links at the final component. Users of filesystem-backed worktrees should upgrade to a patched version. Credits Thanks to @kodareef5 for reporting this issue and working with the go-git security team toward its resolution. 🥇 We would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=6.0.0-alpha.4 Fixed version 6.0.0-alpha.5 CVSS Score 6.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:L EPSS Score 0.413% EPSS Percentile 34th percentile Description Impact A path traversal issue in go-git could allow malicious reference names to access files outside the repository's intended reference storage. Loose references are stored under .git/<reference-name>. The reference name was previously used as a path without verifying that the resolved path remained within the reference storage. A name such as refs/heads/../../config could therefore resolve to unrelated repository metadata such as .git/config or .git/HEAD. A malicious Git server could advertise such a reference name. The name may also survive refspec mapping; for example, it could be mapped to refs/remotes/origin/../../config during a clone or fetch operation. This vulnerability affects filesystem-backed repositories using the storage/filesystem package and its dotgit reference storage. Users relying exclusively on the in-memory storage implementation, storage/memory, are not affected, because reference names are not resolved as filesystem paths. Exploitation requires an application using go-git with filesystem-backed storage to interact with a malicious Git server or otherwise process attacker-controlled reference names. Patches The issue has been addressed by validating reference names at the dotgit storage entry points and rejecting names whose resolved paths could escape the reference storage. Users of filesystem-backed storage should upgrade to a patched version. Workarounds Applications that exclusively use storage/memory are not affected and do not require a workaround for this vulnerability. For applications using filesystem-backed storage, avoid cloning from or fetching from untrusted Git servers until an upgrade is possible. Applications that directly construct or process reference names may also validate them before passing them to filesystem-backed go-git storage. Application-level validation should only be considered a temporary mitigation and does not replace upgrading to a patched version. References Fixes: storage: dotgit, reject path traversal in reference names go-git/go-git#2247 storage: dotgit, reject path traversal in reference names go-git/go-git#2254 Credits Thanks to @Saku0512 for reporting this issue and @Sahana2524 for proposing the initial fix. 🙇

golang.org/x/crypto 0.55.0 (golang) pkg:golang/golang.org/x/crypto@0.55.0 Affected range >=0 Fixed version Not Fixed Description The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used. If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.

[github-actions]

Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/33674678587.

[github-actions]

PR is clean and can be merged. See https://github.com/uniget-org/tools/actions/runs/33674678587.