Apple Mac OS X Find-By-Content

This plugin fires when a web server will hand out a /.DS_Store file, a macOS Finder metadata artifact that can reveal file and directory names in that folder and sometimes stale names for deleted items. In practice the affected population is not all Macs but web content copied from Mac workstations onto any HTTP server without filtering dotfiles; Tenable maps it to the old Find-By-Content era (Mac OS X 10.0 through 10.0.4) and scores it as generic information disclosure.

Tenable's MEDIUM label is too generous for enterprise patch prioritization. The real-world chain requires the file to be present, exposed over HTTP, and valuable enough that the leaked filenames lead to something else; that's a lot of friction for a bug that by itself gives no code execution, no auth bypass, and no write path.

Why this verdict

• Starts as confidentiality-only: the vendor vector already says C:L/I:N/A:N; there is no direct code execution, tampering, or outage path.
• Requires a very specific attacker position: unauthenticated remote is possible, but only if a guessed directory contains a .DS_Store and the server serves dotfiles. That sharply reduces the reachable population from 'all web servers' to a mispublished subset.
• Implies no initial compromise, but usually yields only reconnaissance: the file leak mainly gives names and paths. Attack value depends on discovering a second exposed asset, so the chain compounds downward after the initial request.
• Modern controls should stop or shrink it: standard web-server dotfile denies, CI/CD packaging, artifact hygiene, and WAF/log review all break the path early. In many enterprises those controls are already present even when scanners still catch isolated exceptions.
• No active exploitation pressure: no KEV listing and no reviewed campaign reporting means there is no evidence this deserves emergency patch treatment.

Why not higher?

If this were routinely leading to credential theft or public admin takeover on its own, the score would move up. It does not: the attacker still needs the file to be exposed and then needs another reachable sensitive object behind the leaked names, which is a separate failure condition.

Why not lower?

It is still Internet-reachable if present, trivially testable, and sometimes leaks exactly the filenames defenders hoped obscurity would hide. In environments that publish ad hoc content from Macs, it can materially aid discovery of backups, exports, staging assets, or forgotten admin files.

1. Block dotfiles at the web tier — Add explicit deny rules for /.DS_Store and preferably all hidden dotfiles at the reverse proxy and origin. For a LOW verdict there is no SLA; treat as backlog hygiene, but this is the cleanest control because it covers future developer mistakes too.
2. Purge .DS_Store from publish paths — Scan web roots, static site artifacts, object-storage website buckets, and deployment bundles for .DS_Store, then remove them before release. For LOW, there is no SLA; treat as backlog hygiene and fold it into standard release hardening.
3. Harden Mac publishing workflows — On Mac endpoints used for content staging, disable writing .DS_Store to network shares where practical and add artifact exclusions in build/deploy tooling. For LOW, there is no SLA; treat as backlog hygiene and land it in your developer platform baseline.
4. Hunt for follow-on access — Search HTTP logs for requests to /.DS_Store and then inspect adjacent requests for leaked filenames, backup extensions, and admin paths. This helps distinguish harmless scanner noise from someone using the file as a recon seed.

Run this from an auditor workstation or CI runner that can reach the target URL. Invoke it as bash check-dsstore.sh https://www.example.com/suspect/path/; it needs no privileges and reports whether /.DS_Store is directly downloadable from that path.

#!/usr/bin/env bash
# check-dsstore.sh
# Simple remote verifier for exposed .DS_Store files over HTTP(S)
# Usage: bash check-dsstore.sh https://www.example.com/path/
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage error

set -u

if [ "$#" -ne 1 ]; then
  echo "Usage: $0 <base-url>"
  exit 3
fi

BASE_URL="$1"
BASE_URL="${BASE_URL%/}"
TARGET_URL="${BASE_URL}/.DS_Store"
TMP_BODY="$(mktemp 2>/dev/null || echo /tmp/dsstore.$$)"
TMP_HDR="$(mktemp 2>/dev/null || echo /tmp/dsstore_hdr.$$)"
trap 'rm -f "$TMP_BODY" "$TMP_HDR"' EXIT

HTTP_CODE=$(curl -k -sS -L \
  -D "$TMP_HDR" \
  -o "$TMP_BODY" \
  -w "%{http_code}" \
  --connect-timeout 10 \
  --max-time 20 \
  "$TARGET_URL" 2>/dev/null)
CURL_RC=$?

if [ $CURL_RC -ne 0 ]; then
  echo "UNKNOWN - request failed for $TARGET_URL"
  exit 2
fi

BODY_SIZE=$(wc -c < "$TMP_BODY" 2>/dev/null || echo 0)
CONTENT_TYPE=$(awk 'BEGIN{IGNORECASE=1} /^Content-Type:/ {print $2; exit}' "$TMP_HDR" | tr -d '\r')

case "$HTTP_CODE" in
  200|206)
    if [ "$BODY_SIZE" -gt 32 ]; then
      # If the response looks like an HTML error page, keep it UNKNOWN.
      if grep -Eiq '<html|<!doctype html|access denied|not found|forbidden' "$TMP_BODY"; then
        echo "UNKNOWN - HTTP $HTTP_CODE but body looks like an error page at $TARGET_URL"
        exit 2
      fi
      echo "VULNERABLE - downloadable .DS_Store detected at $TARGET_URL (HTTP $HTTP_CODE, ${BODY_SIZE} bytes, content-type: ${CONTENT_TYPE:-unknown})"
      exit 1
    else
      echo "UNKNOWN - HTTP $HTTP_CODE but body too small to confirm .DS_Store at $TARGET_URL"
      exit 2
    fi
    ;;
  401|403|404)
    echo "PATCHED - .DS_Store not directly downloadable at $TARGET_URL (HTTP $HTTP_CODE)"
    exit 0
    ;;
  *)
    echo "UNKNOWN - unexpected HTTP $HTTP_CODE for $TARGET_URL"
    exit 2
    ;;
esac

Sources

1. Tenable Nessus Plugin 10756
2. Tenable Plugin 10756 changelog
3. CVE Details - CVE-2001-1446
4. Feedly CVE page - CVE-2001-1446
5. CISA KEV catalog mirror
6. FIRST EPSS documentation
7. Intego on .DS_Store exposure
8. Juniper IPS signature HTTP:INFO-LEAK:DS-STORE