Search: backup.bat
6 threats
Most recently published first
| Severity | CVSS | Signals | Threat | Source | Published | Score and star |
|---|---|---|---|---|---|---|
| High | 7.8 | EPSS 0.1% | CVE-2026-119333jgraph drawio-desktop · Untrusted Search Path High7.8EPSS 0.1%CVE Database V5CVE-2026-119333 draw.io Desktop is the official Electron build of draw.io. Prior to 31.5.2, the Windows application launched powershell and attrib by bare executable name from src/main/electron.js. When draw.io Desktop was not already running, opening a diagram from File Explorer made the diagram directory the current working directory, allowing a colocated attacker-controlled powershell.bat or attrib.exe to be resolved before the intended system executable. A victim who extracted an attacker-supplied archive and cold-opened its legitimate .drawio file could therefore execute attacker-controlled code when Local Fonts were enabled or when draft or backup attributes were updated. This issue is fixed in version 31.5.2. | CVE Database V5 | ||
| Critical | 9.1 | EPSS 0.3% | Critical9.1EPSS 0.3%CVE Database V5CVE-2026-63160 CVE-2026-63160 affects Omnispace Agora Project versions before 26.10.0. The vulnerability involves storing the persistent remember-me token verbatim on the server side, making it identical to the bearer token in the user's cookie. If an attacker obtains this stored token, for example via database or backup disclosure, they can replay it to authenticate as the victim without needing the user's password. This issue was fixed in version 26.10.0. EPSS 0.3%Vulnerability | CVE Database V5 | ||
| High | 7.2 | EPSS 0.3% | CVE-2026-75962Post SMTP (WordPress plugin) · Cross-site Scripting High7.2EPSS 0.3%CVE Database V5CVE-2026-75962 Post SMTP plugin for WordPress versions up to 4.0.1 is vulnerable to stored cross-site scripting (XSS) via the 'user_email' parameter. This vulnerability allows unauthenticated attackers to inject malicious scripts that execute when a user views the affected page. The issue arises from insufficient input sanitization and output escaping, particularly on WordPress Multisite installations with public registration enabled. Attackers can exploit this by submitting email addresses with numeric HTML character references that bypass Post SMTP's validation and get logged verbatim. | CVE Database V5 | ||
| Low | 1.8 | EPSS 0.2% | CVE-2026-82723team-alembic ash_authentication · Sensitive Data in Logs Low1.8EPSS 0.2%CVE Database V5CVE-2026-82723 Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store. The audit_log add-on builds each entry's extra_data in AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/4, which takes :actor from the action callback context verbatim. Any audited action invoked with actor: set to a user record therefore deposits that record, including its hashed_password attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.user_to_subject/1 and filters params against the strategy's configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute sensitive?: true does not help, because that redacts inspect/1 output rather than JSON encoding or raw-term storage. There is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker's own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises Protocol.UndefinedError and drops the entry unless the user resource derives Jason.Encoder. This issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2. | CVE Database V5 | ||
| Low | 2.1 | EPSS 0.4% | Low2.1EPSS 0.4%GCVE DatabaseCVE-2026-48754 ## Summary `(*backend).createDependentVolumesFromBackup` in [`internal/server/storage/backend.go`](https://github.com/lxc/incus/blob/d768f81c0a1d985f35ae56219519822b080bf5e3/internal/server/storage/backend.go) contains a cluster of unguarded pointer derefs on every dependent-volume entry's `VolumeSnapshots[i]`, `Volume`, and `Pool` sub-fields. An authenticated user with `can_create_instances` permission on any project can crash the `incusd` daemon by uploading an instance backup tarball whose `dependent_volumes[*]` block contains a nil snapshot pointer (or omits `volume:` / `pool:`). This is a sibling-field variant of the 2026-05-04 batch fix `d768f81c0a1d985f35ae56219519822b080bf5e3` ("Properly check dependent volumes on import"). That commit added `if disk == nil` at the top of the outer loop, but did not guard the four sub-pointer fields the loop body dereferences naked. ## Vulnerable code [`internal/server/storage/backend.go:9352-9412`](https://github.com/lxc/incus/blob/d768f81c0a1d985f35ae56219519822b080bf5e3/internal/server/storage/backend.go#L9352-L9412): ```go func (b *backend) createDependentVolumesFromBackup(srcBackup backup.Info, ...) error { ... for _, disk := range srcBackup.Config.DependentVolumes { if disk == nil { // ← d768f81 parent fix return errors.New("Bad dependent volume definition found in index") } ... snapshots := []string{} for _, snap := range disk.VolumeSnapshots { snapshots = append(snapshots, snap.Name) // ← I-2 trigger: snap may be nil } bInfo := backup.Info{ Project: disk.Volume.Project, // ← disk.Volume may be nil Name: disk.Volume.Name, Backend: disk.Pool.Driver, // ← disk.Pool may be nil Pool: disk.Pool.Name, ... } ... devKey := fmt.Sprintf("%s/%s", disk.Pool.Name, disk.Volume.Name) ... } } ``` `disk` has type `*config.Config` (declared in [`internal/server/backup/config/backup_config.go:8`](https://github.com/lxc/incus/blob/d768f81c0a1d985f35ae56219519822b080bf5e3/internal/server/backup/config/backup_config.go#L8)). Its `Volume` field is `*api.StorageVolume`, `Pool` is `*api.StoragePool`, `VolumeSnapshots` is `[]*api.StorageVolumeSnapshot` — all yaml `omitempty`. YAML omission decodes to nil for each. The parent fix mental-modeled "outer-iteration variable nil"; it did not walk every sub-field deref inside the loop body. Direct asymmetric-guard variant. ## Reach 1. Attacker is an authenticated client with `can_create_instances` on any project. Same auth gate as GHSA-8g7m-96c8-8wwc / CVE-2026-47753. 2. `POST /1.0/instances` with `Content-Type: application/octet-stream` and `X-Incus-name: <name>`. 3. Body is a tar containing [`backup/index.yaml`](https://github.com/lxc/incus/blob/d768f81c0a1d985f35ae56219519822b080bf5e3/backup/index.yaml) whose `config:` block has a non-nil `container:` (passes `instances_post.go:854 if bInfo.Config == nil || bInfo.Config.Container == nil`) and a `dependent_volumes:` list with a malformed entry. 4. Chain: `instancesPost` -> `createFromBackup:854` (Container guard passes) -> `pool.CreateInstanceFromBackup` -> `backend.go:782 b.createDependentVolumesFromBackup` -> `backend.go:9374 snap.Name` panics on the nil `*api.StorageVolumeSnapshot` element. 5. `incusd` dies. Persistent DoS on repeat. Minimal [`backup/index.yaml`](https://github.com/lxc/incus/blob/d768f81c0a1d985f35ae56219519822b080bf5e3/backup/index.yaml) (used in the bundled PoC): ```yaml name: poc-inst backend: dir pool: default type: container optimized: false optimized_header: false snapshots: [] config: container: name: poc-inst architecture: x86_64 type: container profiles: ["default"] config: {} devices: {} expanded_devices: depdisk: {type: disk, dependent: "true", pool: default, source: depvol, path: /data} expanded_config: {} dependent_volumes: - volume: {name: depvol, type: custom, content_type: filesystem, config: {}} pool: {name: default, driver: dir, config: {}} volume_snapshots: - ~ # explicit null entry → snap.Name at 9374 panics ``` (The container block must declare at least one device with `type: disk`, `dependent: "true"`, `pool != ""`, `path != "/"` to populate `devicesMap` and reach the second loop. Trivially satisfiable.) An equivalent triggering YAML omits `volume:` or `pool:` from the dependent_volumes entry; in that case `disk.Volume.Project` at 9378 panics instead. ## Proof of concept (end-to-end against running daemon) Bundled in the report: `make_backup.sh` + 666-byte `poc-inst.tar.gz`. Tested against `incus 7.0.0` (zabbly latest GA, build `1:0~ubuntu24.04~202605201355`) inside a privileged Ubuntu 24.04 container with default `dir` pool. ```bash $ curl -s --unix-socket /var/lib/incus/unix.socket - | GCVE Database | ||
| Low | 3.8 | EPSS 0.3% | Low3.8EPSS 0.3%CVE Database V5CVE-2025-10306 The Backup Bolt plugin for WordPress is vulnerable to arbitrary file downloads and backup location writes in all versions up to, and including, 1.4.1 via the process_backup_batch() function. This makes it possible for authenticated attackers, with Administrator-level access and above, to download directories outside of the webroot and write backup zip files to arbitrary locations. | CVE Database V5 |
Page 1 of 1