Debian DSA-6449-1: OpenStack Swift SSRF and Authorization Bypass Flaws — Detection and Remediation Guide

Debian's security team has published DSA-6449-1, addressing multiple vulnerabilities in OpenStack Swift — the open-source object storage engine that underpins countless private clouds, service-provider storage platforms, and on-prem S3-compatible backends. The advisory flags flaws that can lead to information disclosure and authorization bypass, with at least one issue carrying classic server-side request forgery (SSRF) characteristics. Debian is urging all users running Swift to apply the updated packages immediately.

If you operate Swift proxy or storage nodes — whether as a standalone OpenStack deployment, a SwiftStack legacy environment, or as the storage layer behind backup platforms and media archives — treat this as a priority patch cycle. Object storage sits directly in the data path: an authorization bypass here is not a theoretical ACL problem, it is unauthenticated or cross-tenant access to the actual payload data your organization is storing.

Technical Analysis

What Swift Is and Why These Flaws Matter

Swift's architecture separates the proxy server (the HTTP front door that authenticates requests and routes them) from account, container, and object servers (the backend storage daemons). In a healthy deployment, only the proxy tier is exposed to clients; the storage nodes trust internal traffic implicitly. This design assumption is exactly what makes SSRF-class bugs in the proxy tier so dangerous: if an attacker can coerce the proxy into making requests on their behalf, or trick it into mis-evaluating authorization, they can pivot from an untrusted external position into the trusted internal storage network.

According to DSA-6449-1, the patched issues enable:

• Server-Side Request Forgery (SSRF) — an attacker can influence server-initiated requests, potentially reaching internal services, metadata endpoints, or backend storage daemons that are not meant to be client-reachable.
• Information disclosure — responses leak data the requesting identity should not be able to read, which in practice often means cross-container or cross-account object metadata and content.
• Authorization bypass — requests that should be rejected by Swift's auth middleware (tempauth, Keystone integration, or reseller-prefixed ACLs) are incorrectly honored.

Affected Products

• Product: OpenStack Swift (the swift source package in Debian)
• Distribution: Debian stable releases shipping Swift — apply the fixed package versions referenced in DSA-6449-1 for your release (the advisory pins corrected versions per Debian suite)
• Component focus: the proxy-server request-handling and authorization middleware path
• Exposure prerequisite: the Swift proxy endpoint must be reachable by the attacker. For internet-facing or multi-tenant Swift, that bar is already met. For internal-only clusters, the residual risk is a malicious insider or any compromised workload with network access to the proxy.

Attack Chain (Defender's View)

1. Attacker authenticates with low-privilege credentials — or, depending on the auth middleware configuration, sends crafted requests without valid credentials.
2. Crafted HTTP requests to the proxy exploit the SSRF weakness, causing the proxy to issue requests to internal endpoints or to mis-attribute the requesting identity.
3. The authorization evaluation flaw allows the request to succeed where it should be denied — reading objects or metadata across account boundaries.
4. Result: bulk data exposure from an object store that operators reasonably believed was tenant-isolated.

The exploitation requirements are low: no race conditions, no memory corruption, no local access — just HTTP requests against the proxy. That is precisely the profile of vulnerability that gets weaponized quickly once patch diffs are public.

Exploitation Status

At the time of DSA-6449-1's publication there is no confirmed public in-the-wild exploitation campaign and no CISA KEV listing tied to this advisory. However, Swift is a high-value target: it stores backups, VM images, and application data at scale. Post-advisory patch-diffing against mature open-source projects is a matter of days, not weeks. Do not let the absence of a KEV entry drive your prioritization — the exploitability bar here is trivially low.

Detection & Response

Patching is the fix, but you need to answer two questions in parallel: are we vulnerable right now, and did anyone probe or exploit the authorization path before we patched. The detections below target observable behaviors of SSRF and authorization-bypass abuse against a Swift proxy.

Sigma Rules

The highest-signal, lowest-noise observable for SSRF against Swift is the proxy process initiating outbound connections to internal/link-local destinations it has no business touching — particularly cloud metadata endpoints — and unusual request patterns against the proxy itself. Scope the network rule to hosts you have tagged as Swift proxy nodes to avoid fleet-wide noise.

---
title: Swift Proxy Server Outbound Connection to Internal or Metadata Endpoint
description: Detects the Swift proxy process initiating network connections to link-local metadata services, loopback, or RFC1918 storage-network destinations, consistent with SSRF exploitation against OpenStack Swift per Debian DSA-6449-1.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6449-1-swift
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/15
status: experimental
logsource:
  product: linux
  category: network_connection
detection:
  selection_img:
    Image|endswith:
      - '/swift-proxy-server'
      - '/swift-proxy'
      - 'proxy-server'
  selection_dst:
    DestinationIp|cidr:
      - '169.254.0.0/16'
      - '127.0.0.0/8'
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/8'
  condition: selection_img and selection_dst
falsepositives:
  - Legitimate proxy-to-storage-node traffic on the internal storage network is expected; tune by excluding known storage node CIDRs and keep alerts on metadata/loopback destinations
level: high
---
title: Suspicious Swift Proxy Process Spawning Shell or Utility
description: Detects the Swift proxy-server process spawning shells or network utilities, a strong post-exploitation signal following compromise of the proxy tier referenced in Debian DSA-6449-1.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6449-1-swift
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
status: experimental
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '/swift-proxy-server'
      - '/swift-proxy'
      - 'proxy-server'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
  condition: selection_parent and selection_child
falsepositives:
  - Rare; Swift proxy workers do not spawn shells or download tools in normal operation. Custom middleware or health-check wrappers may — validate against your deployment
level: critical
---
title: Repeated Swift Authorization Failures Followed by Success from Same Source
description: Detects a source IP generating bursts of 401/403 responses from the Swift proxy followed by successful 2xx responses, consistent with probing and then bypassing authorization as described in Debian DSA-6449-1. Apply to Swift proxy access logs forwarded to your SIEM.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6449-1-swift
  - https://attack.mitre.org/techniques/T1110/
author: Security Arsenal
date: 2026/01/15
status: experimental
logsource:
  category: webserver
detection:
  selection:
    c-uri|startswith: '/v1/'
    sc-status:
      - 401
      - 403
  condition: selection
falsepositives:
  - Expired token churn from legitimate clients; this rule is intended as a building block for threshold-based correlation (e.g., >20 failures from one source in 5 minutes), not standalone alerting
level: medium

KQL — Microsoft Sentinel Hunt

If your Swift proxy access logs (or WAF/reverse-proxy logs in front of Swift) are ingested into Sentinel via Syslog/CEF or a custom table, this hunt surfaces clients whose request pattern shifted from denied to allowed — the behavioral fingerprint of an authorization-bypass probe that eventually succeeded. It also flags requests containing internal IP literals or metadata hostnames in URL/query parameters, the classic SSRF tell.

let lookback = 7d;
let denied =
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where RequestURL startswith "/v1/" or RequestURL contains "/v1/"
    | where EventOutcome in ("401", "403") or AdditionalExtensions has_any ("401", "403")
    | summarize DeniedCount = count() by SourceIP, bin(TimeGenerated, 5m);
let succeeded =
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where RequestURL contains "/v1/"
    | where EventOutcome in ("200", "201", "204")
    | summarize SuccessCount = count(), FirstSuccess = min(TimeGenerated) by SourceIP;
denied
| join kind=inner succeeded on SourceIP
| where DeniedCount >= 10 and SuccessCount >= 1
| project SourceIP, DeniedCount, SuccessCount, FirstSuccess
| order by DeniedCount desc;
// Companion hunt: SSRF-shaped parameters in Swift requests
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where RequestURL contains "/v1/"
| where RequestURL has_any ("169.254.169.254", "127.0.0.1", "localhost", "metadata.google", "0.0.0.0", "10.", "192.168.", "172.16.")
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, EventOutcome
| order by TimeGenerated desc;

Velociraptor VQL — Proxy Host Triage

For IR scoping on the Swift proxy hosts themselves, this artifact collects listening sockets and active connections for the Swift processes plus a package-version check, so you can confirm exposure and hunt for suspicious proxy-initiated connections in one pass.

-- DSA-6449-1 Swift proxy triage: version, listeners, and proxy-initiated connections
LET conns = SELECT Pid, Name, Status, Laddr, Raddr
FROM netstat()
WHERE Name =~ 'swift' OR Name =~ 'proxy-server'

LET procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'swift' OR CommandLine =~ 'swift-proxy'

SELECT * FROM procs
UNION ALL
SELECT Pid, Name, format(format='L:%v -> R:%v', args=[Laddr, Raddr]) AS CommandLine,
       Status AS Exe, '' AS Username, '' AS CreateTime
FROM conns

For the version check, run a one-off VQL shell exec or simply use the remediation script below across the fleet — knowing your installed swift package version against the DSA-6449-1 fixed version is the fastest exposure answer you will get.

Remediation and Verification Script

Run on Debian-based Swift proxy and storage nodes. It reports the current package state, applies the security update, restarts Swift services, and verifies the patched version landed.

#!/usr/bin/env bash
# DSA-6449-1 Swift remediation + verification — run as root or via sudo
set -euo pipefail

echo "=== [1/4] Current Swift package state ==="
dpkg -l | grep -E 'swift|python3-swift' || echo "No swift packages installed on this host."

echo "=== [2/4] Refreshing security repos and upgrading Swift ==="
apt-get update -o Dir::Etc::sourcelist="sources.list.d/*security*" 2>/dev/null || apt-get update
apt-get install --only-upgrade -y swift python3-swift swift-proxy swift-account swift-container swift-object 2>/dev/null \
  || apt-get install --only-upgrade -y swift python3-swift

echo "=== [3/4] Restarting Swift services ==="
if command -v swift-init >/dev/null 2>&1; then
  swift-init all restart
else
  systemctl list-units --type=service --no-legend | awk '/swift/ {print $1}' | xargs -r systemctl restart
fi

echo "=== [4/4] Post-patch verification ==="
INSTALLED=$(dpkg-query -W -f='${Version}\n' swift 2>/dev/null || echo "not-installed")
echo "Installed swift version: ${INSTALLED}"
echo "Compare against the fixed version listed in DSA-6449-1 for your Debian release:"
echo "  https://www.debian.org/security/ (search DSA-6449-1)"
systemctl --no-pager --failed | grep -i swift && echo "WARNING: failed swift units present" || echo "No failed swift units."
echo "=== Done. Review /var/log/swift/ and your proxy access logs for pre-patch probing. ==="

Remediation

1. Patch immediately. Apply the fixed Swift packages from DSA-6449-1 via apt-get upgrade (or the targeted script above) on every node running Swift — proxy tier first, then storage nodes. Confirm the installed version matches the fixed version Debian lists for your release suite. Official advisory: https://linuxsecurity.com/advisories/debian/debian-dsa-6449-1-swift and the canonical record at https://www.debian.org/security/.
2. Inventory your exposure. Identify every host with swift-proxy-server listening, and determine which proxy endpoints are reachable from untrusted networks. Multi-tenant and internet-facing proxies move to the front of the patch queue.
3. Review pre-patch telemetry. Hunt the last 7–30 days of proxy access logs for the patterns in the KQL above: denied-to-allowed source transitions, requests containing internal IP literals or metadata hostnames, and any access of containers/accounts by identities with no legitimate relationship to them.
4. Restrict the blast radius while patching. Place the Swift proxy behind a WAF or reverse proxy that strips or blocks requests containing link-local/loopback/RFC1918 destinations in user-controlled parameters. Enforce egress filtering on proxy hosts so they can only reach your declared storage-node subnets — this neuters the SSRF class generically, not just this advisory.
5. Rotate credentials if you find hits. If hunting reveals suspicious successful reads, treat stored tokens, tempauth credentials, and Keystone service credentials as potentially exposed. Rotate them and review object-level access logs for exfiltration volume.
6. Verify tenant isolation post-patch. Run negative authorization tests: valid credentials from account A attempting reads against account B must return 403. Bake this into regression testing for future Swift upgrades.

Do not defer this one. Storage-layer authorization bypasses are quiet — there is no crash, no ransom note, just data leaving through the front door with a valid-looking request. Patch, hunt, and verify isolation.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub