Trivy v0.69.2 fails to scan python:3.12.13-slim with invalid tar header

[akashkumar975]

Description

Trivy v0.69.2 fails to scan Docker images based on python:3.12.13-slim (released March 4, 2026) with archive/tar: invalid tar header. The same Dockerfile scans fine when using python:3.12.12-slim (released Feb 27, 2026).

The image builds and runs perfectly with Docker — only Trivy's scanner fails.

What did you expect to happen?

Trivy should scan python:3.12.13-slim successfully, same as it does with python:3.12.12-slim.

What happened instead?

FATAL  Fatal error  run error: image scan error: scan error: scan failed: failed analysis:
  analyze error: pipeline error: failed to analyze layer
  (sha256:f9c7c89d8eb9a68ee6ca70eea8cfae3309ec0bef792e4cf3f36a20fd778e59e6):
  walk error: failed to extract the archive: archive/tar: invalid tar header

Reproduction Steps

# This FAILS
docker pull python:3.12.13-slim
trivy image python:3.12.13-slim

# This WORKS
docker pull python:3.12.12-slim
trivy image python:3.12.12-slim

Root Cause Analysis

We traced the error through Trivy source code:

1. pkg/fanal/walker/tar.go calls tar.NewReader(layer) then tr.Next()
2. tr.Next() calls Go standard library archive/tar -> readHeader() -> blk.getFormat()
3. getFormat() fails checksum validation -> returns FormatUnknown
4. readHeader() returns ErrHeader ("archive/tar: invalid tar header")
5. Trivy wraps it as "failed to extract the archive: archive/tar: invalid tar header"

Layer Comparison

Both images use Debian Trixie. The base Debian layer (Layer 0) is identical. Only the Python-specific layers differ:

Layer	Purpose	3.12.12-slim (works)	3.12.13-slim (fails)
0	Debian Trixie base	sha256:206356c424... (29.7 MB)	sha256:206356c424... (29.7 MB) - Same
1	apt-get packages	sha256:a546a81ba9... (1,292,721 bytes)	sha256:30dad65d3b... (1,292,722 bytes) - Changed
2	Python compiled	sha256:90b93dccd5... (12,112,324 bytes)	sha256:5d7ccc6599... (12,112,897 bytes) - Changed
3	Symlinks	sha256:2d517a4d89... (248 bytes)	sha256:b9aab63c29... (251 bytes) - Changed

What Changed in python:3.12.13

• Python 3.12.13 released March 3, 2026 (security patch)
• Docker Hub rebuilt python:3.12-slim on March 4
• Key changes: libexpat upgraded to 2.7.4, SSL module fix (C-level recompilation)
• The Dockerfile template is identical between versions - only PYTHON_VERSION changed
• Docker Hub build infrastructure repackaged the layers, producing tar headers that Go archive/tar cannot parse

Target

Container Image

Scanner

Vulnerability

Output Format

Table

Mode

Standalone

Environment

• Trivy version: v0.69.2 (also checked v0.69.3 - only has go-git bump, does not fix this)
• Go version (in Trivy): 1.25.6
• Image scanned: python:3.12.13-slim (sha256:d6b046b27fe57002af7655dd6aa4ce3bc8a42a4621d7a5b4056a417e0d9952f5)
• Working image: python:3.12.12-slim (sha256:42f1689d6d6b906c7e829f9d9ec38491550344ac9adc01e464ff9a08df1ffb48)
• Scan method: Via Docker socket (-v /var/run/docker.sock:/var/run/docker.sock)
• OS: Ubuntu (GitHub Actions runner)

Impact

This blocks security scanning CI pipelines for any project using python:3.12.13-slim (or python:3.12-slim which now points to 3.12.13). The only workaround is to pin to python:3.12.12-slim. As more upstream images get rebuilt by Docker Hub, this issue will likely affect additional base images beyond Python.

[DmitriyLewen]

Hi @akashkumar975 ,

I tried to reproduce your problem (locally and in Ubuntu images (amd64 and arm64)).
In all cases, I get correct scanning.

Perhaps you have an example pipeline with the error?

Can you also share docker info and try "--image-src registry` flag?

Regards, Dmitriy

[slrwin]

@DmitriyLewen I have the same issue with Linux based image for our application. Debug log and other details are provided in the other bug.

#10348

Following are the steps from our azure devops pipeline.

`

  - task: Docker@2
    displayName: Build an image
    inputs:
      repository: ${{ parameters.imageName }}
      command: build
      arguments: --platform linux/amd64
      Dockerfile: ${{ parameters.folder }}/Dockerfile
      buildContext: ${{ parameters.folder }}
      tags: |
        ${{ tag }}
        ${{ tag }}-$(DATE_TAG)
      containerRegistry: ContainerRegistry1
  - bash: |
      echo ".trivyignore contents:"
      cat .trivyignore
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b . -d v0.69.3
      docker save --platform linux/amd64 -o image.tar xyzrepo/${{ parameters.imageName }}:${{ tag }}-$(Build.BuildNumber)
      ./trivy image --exit-code 0 --severity MEDIUM,HIGH --ignore-unfixed --input image.tar 
      run_trivy() {
        local retries=5
        local count=0
        local success=0

        while [ $count -lt $retries ]; do
          ./trivy image --exit-code 0 --severity MEDIUM,HIGH --ignore-unfixed --input image.tar $
          if [ $? -eq 0 ]; then
           success=1
           break
          else
           echo "Trivy scan failed. Retrying in 60 seconds..."
           sleep 60
           count=$((count + 1))
          fi
        done
          if [ $success -eq 0 ]; then
             echo "Trivy scan failed after $retries attempts."
             exit 1
          fi
       }

       # Run Trivy scan with retries
      run_trivy

      if ./trivy image --exit-code 1 --severity CRITICAL --ignore-unfixed --input image.tar ${{ parameters.scanOptions }} --vuln-type library hazelcast:3.12.12; then
        if [ -f ".trivyignore" ]; then rm .trivyignore; fi
      else
        ./trivy image --exit-code 0 --severity CRITICAL --ignore-unfixed --input image.tar ${{ parameters.scanOptions }} --vuln-type library hazelcast:3.12.12
      fi
    displayName: Scan
    # workingDirectory: ${{ parameters.repository }}

`

[knqyf263]

I also tried to reproduce this locally but couldn't, same as @DmitriyLewen.

A few questions:

• Is this error consistently reproducible in your environment, or does it happen intermittently?
• Could you check if the disk on your CI runner (GitHub Actions / Azure DevOps) has enough free space? If the disk is nearly full, docker save or layer extraction could produce a truncated/corrupted tar archive.
• Could you also try --image-src remote to scan directly from the registry, bypassing Docker?

[slrwin]

@knqyf263

• In our case this issue is consistent on every run after we updated from v0.56.2 to v0.69.3, earlier we don't have this issue. We also noticed v0.56.2 is now not available in releases.
• We have enough free space for CI runner on the Agent hosts.
• Unable to run --image-src remote as its a local image

[slrwin]

@DmitriyLewen @knqyf263 Can we get the v0.56.2 version release added to check this issue?

[DmitriyLewen]

We're still looking for a solution to restore releases.
But you can build the version you need from source.

[slrwin]

Thank you! trying to build the version from the source for now.

[slrwin]

@DmitriyLewen I tried to build v0.56.2 from source there also I see the same issue.

On our Azure Agent pools we have noticed 2 changes with respect to Docker.

1. Docker task updated to 2.269.0
2. Docker updated to version 29.3

Suspecting the docker save step is saving the tar file in different format compared to earlier versions.

[DmitriyLewen]

Hi @slrwin ,
I tried to reproduce your case.

• I tried to do this on a local machine.
• I also tried using an Ubuntu machine from GitHub Actions (https://github.com/DmitriyLewen/test-trivy-action/actions/runs/23232316141).

The result is not reproducible. Are you still seeing this error?