PAGES
← all tools
◆ Reverse Engineering

checksec.sh

3.2.0 open-source

Checks security properties of executables (PIE, RELRO, stack canaries, NX, FORTIFY_SOURCE) and kernel configurations on Linux systems.

Summary

checksec.sh is an open-source command-line tool that inspects the security properties of ELFELFThe standard binary format for executables, shared libraries, and object files on Linux and most Unix-like systems, giving cyber tools a predictable structure to parse, instrument, or analyze compiled code. binaries, running processes, and the Linux kernel — RELRO, stack canaries, NX, PIE, RPATH/RUNPATH, FORTIFY_SOURCE, CFI, and related hardening flags — and is free to use. It ships as a single static Go binary, installable from a release download, a .deb/.rpm/.apk package, Docker image, or go install, and runs against a file, a directory recursively, a running process by PID, or the live kernel. It suits reverse engineers and security engineers who need to verify hardening on binaries or CI build artifacts, including a --fail-if flag for gating pipelines on missing protections. It is a modern rewrite of Tobias Klein's original 2011 bash script, extending it with checks like SafeStack, sanitizer detection, and W^X segment analysis. With 69 contributors, 99 commits and 11 releases in the past year, and a release only 65 days old, it is actively maintained.

Checks security properties of executables (PIE, RELRO, stack canaries, NX, FORTIFY_SOURCE) and kernel configurations on Linux systems.

How checksec.sh helps

Which of my binaries are missing stack protection or would let an attacker land a ROP chain?

scans a file or an entire directory tree and reports RELRO, stack canary, NX, PIE, and RPATH/RUNPATH status for each, flagging exactly which hardening flags are absent

Is a process that's already running actually protected, not just the binary on disk?

inspects a live process by its process ID and reports the same hardening properties as loaded in memory, catching cases where the running instance differs from the file

Is this kernel configured with the hardening I expect in production?

reads the running kernel's configuration directly and reports its hardening posture, the same way it reports a binary's

Should this build fail before it ships?

checks a comma-separated list of specific properties like RELRO, canary, or PIE against each artifact and exits non-zero the moment one of them isn't in a good state, so a pipeline can gate on it automatically

If this binary is exploited, which techniques would actually get through?

runs static analysis over imports, relocations, and segment permissions to report which memory-corruption techniques the binary's current mitigations fail to block, citing the specific evidence behind each verdict, without claiming to find the vulnerability itself

all 10 features, with the evidence for each →

Languages

Not documented

Features

10 capabilities · 3 backed by code, an API document or a real run

Built from checksec.sh's releases, docs, README and our own runs. “Seen” marks the month we first spotted a release the vendor didn't date. Group names and tags are our labels.

Compare with peers →

What checksec.sh offers you

  • Command-line interface4
  • CI/CD pipeline integration1
  • CSV data export1
All capabilities 10 capabilities
ELF hardening detection shipped Detects a range of binary hardening properties in ELF files, including RELRO, stack canary, PIE, SafeStack, W^X segments, stack-clash protection, CFI (including i386 CET and RISC-V Zicfilp/Zicfiss), sanitizers (ASAN, UBSAN, MSAN, TSAN, LSAN), Selfrando, FORTIFY, and GLIBCXX assertions. 17 releases · 5 other sources · first seen Jul 2019

release 17 total

  • New sanitizer detection (ASAN, UBSAN, MSAN, TSAN, LSAN) via compiler-rt symbol prefix scan. 3.2.0 · Jun 2026 · source · release history
  • Adds annobin-based FORTIFY and GLIBCXX assertion detection. 3.2.0 · Jun 2026 · source · release history
  • Extends CFI hardening detection to i386 CET and RISC-V Zicfilp/Zicfiss (landing pads and shadow stack), covering both RV32 and RV64. 3.2.0 · Jun 2026 · source · release history
  • Adds SafeStack detection for ELF binaries by scanning for the __safestack_init symbol. 3.2.0 · Jun 2026 · source · release history
  • Detects sanitizer instrumentation (ASAN, UBSAN, MSAN, TSAN, LSAN) via compiler-rt symbol prefix scan. 3.2.0 · Jun 2026 · source · release history
  • New W^X segment check (SeparateCode): flags any PT_LOAD segment that is both writable and executable. 3.2.0 · Jun 2026 · source · release history

docs

  • Checks security properties of executables (PIE, RELRO, stack canaries, NX, FORTIFY_SOURCE) and kernel configurations on Linux systems.

example

  • Suppress advisory warnings and check a binary for the new sanitizer, SafeStack, and W^X properties. checksec --file=/usr/bin/target --no-warnings 3.2.0 · Jun 2026 · source
  • Scan a binary to check for SELinux forced randomness protections and core dump settings. checksec.sh --file=/path/to/binary 2.2.0 · May 2020 · source
  • Check FORTIFY_SOURCE for a process checksec fortifyProc 1
  • Check security properties of a file checksec file /bin/ls
Output formatting controls verified Provides flags to suppress warning output and to control colorized output (auto, always, never), with warnings including filename context. 5 releases · 7 other sources · first seen May 2020

Also counts toward: Command-line interface

release

  • Adds --no-warnings and --color flags; warnings now include filename context. 3.2.0 · Jun 2026 · source · release history
  • New --no-warnings flag suppresses warning output; new --color flag controls colorized output (auto, always, never); warnings now include filename context. 3.2.0 · Jun 2026 · source · release history
  • New flag to disable headers and banners in output, enabling cleaner scripted/automated use. 3.1.0 · Dec 2025 · source · release history
  • Redirects warnings to stderr, separating diagnostic output from structured results. 3.1.0 · Dec 2025 · source · release history
  • Runs readelf in wide mode for enhanced output. 2.2.0 · May 2020 · source · release history

command line

example

  • Run a clean, warning-free scan of a directory with forced color off — useful in log-heavy CI environments where ANSI codes break parsers. checksec dir /opt/app --recursive --no-warnings --color never --output json 3.2.0 · Jun 2026 · source
  • Suppress headers and banners when piping checksec output into a parser or SIEM ingestion script. checksec --file=/usr/bin/sshd --disable-headers-banners 3.1.0 · Dec 2025 · source
  • Output file check results as JSON checksec file /bin/ls --output json
  • Output file check results as XML checksec file /bin/ls --output xml
  • Output file check results as YAML checksec file /bin/ls --output yaml
CI pipeline gating verified Exits with a non-zero status when any specified hardening checks fail, allowing the tool to act as a blocking gate in CI pipelines. 3 releases · 2 other sources · first seen Dec 2025

Also counts toward: CI/CD pipeline integration, Command-line interface

release

  • New --fail-if flag: exits non-zero when any specified check (comma-separated keys, e.g. relro,canary,pie) is not in a good state — enables use as a CI gate. 3.2.0 · Jun 2026 · source · release history
  • New W^X segment check (SeparateCode) asserts no PT_LOAD segment is simultaneously writable and executable. 3.2.0 · Jun 2026 · source · release history
  • Supports binaries with no sections (e.g., stripped or static binaries). 3.1.0 · Dec 2025 · source · release history

command line

  • --fail-if — Exit non-zero if any listed check (comma-separated keys, e.g. relro,canary,pie) is not StatusGood 3.2.0 · Jun 2026 · command-line history

example

  • Gate a CI pipeline on RELRO, canary, and PIE — fail the build if any binary in a directory is missing these hardening properties. checksec dir ./build/bin --recursive --fail-if relro,canary,pie 3.2.0 · Jun 2026 · source
Directory and file-list scanning verified Scans all binaries under a directory recursively or checks every binary listed in a file (or stdin), with parallel execution over a bounded worker pool to reduce syscall overhead. 2 releases · 1 other source · first seen Jun 2026

release

  • Parallel directory scanning (RunListChecksParallel) over a bounded worker pool (default GOMAXPROCS), reducing open syscalls on a recursive /usr/bin scan from ~18k to ~2k. 3.2.0 · Jun 2026 · source · release history
  • Adds parallel directory scanning (RunListChecksParallel) over a bounded worker pool (default GOMAXPROCS). 3.2.0 · Jun 2026 · source · release history

command line

  • listfile — Check every binary listed in a file (or stdin via -) 3.2.0 · Jun 2026 · command-line history
Kernel module scanning shipped Scans kernel modules (.ko files) for security properties alongside regular binaries. 1 release · 2 other sources · first seen Dec 2025

release

  • Supports checking kernel modules (.ko files) as targets. 3.1.0 · Dec 2025 · source · release history

example

  • Check a kernel module for security properties (e.g., RELRO, stack canary) alongside regular binaries. checksec --file=/lib/modules/$(uname -r)/kernel/drivers/net/tun.ko 3.1.0 · Dec 2025 · source
  • Check kernel security settings as JSON checksec kernel --output json
Exploitability reasoning documented Performs static mitigation-obstruction analysis to report which attack techniques the binary's posture fails to obstruct and supports adding hypothesis exploit chains. 2 other sources · first seen Sep 2026

Also counts toward: Command-line interface

docs

  • llm Exit non-zero if any listed check (or exploitability predicate ) fails. See --exploit Append static exploitability reasoning — which attack techniques the mitigation posture fails to obstruct. --chain Add a hypothesis exploit chain to the exploitability output (implies --exploit ). docs update · Sep 2026 · source
  • Exploitability ( --exploit ) --exploit adds static mitigation-obstruction analysis. It reports which memory-corruption techniques the binary's posture fails to block, citing the evidence (imports, relocations, segment permissions) behind each verdict. What it claims — and does not It is not a vulnerability scanner. docs update · Sep 2026 · source
LLM-native reporting documented Emits a self-grounding Markdown report designed to be pasted into an LLM, ensuring the model reasons from the tool's ground truth. 2 other sources · first seen Sep 2026

Also counts toward: Command-line interface

docs

  • LLM output ( -o llm ) -o llm emits a self-grounding Markdown report designed to be pasted into an LLM (Claude, ChatGPT, …). Every report ships its own ground truth so the model reasons from the tool, not from memory. docs update · Sep 2026 · source
  • Beyond reporting the raw mitigation posture, checksec can reason about which attack techniques that posture fails to obstruct exploitability reasoning --exploit ) and emit a self-grounding report you can paste straight into an LLM -o llm ). docs update · Sep 2026 · source
RPATH/RUNPATH entry classification shipped Inspects each RPATH/RUNPATH entry and rates it as bad (relative, empty, or world-writable), warning ($ORIGIN or nonexistent), or info (safe absolute path). 2 releases · first seen Jun 2026

release

  • New RPATH/RUNPATH entry classifier: rates each entry as bad (relative/empty/world-writable), warning ($ORIGIN/nonexistent), or info (safe absolute). 3.2.0 · Jun 2026 · source · release history
  • New RPATH/RUNPATH inspection classifies each entry as bad (relative/empty/world-writable), warning ($ORIGIN or nonexistent), or safe (absolute). 3.2.0 · Jun 2026 · source · release history
Machine-readable output shipped Emits check results as CSV for ingestion into spreadsheets or SIEMs. 1 other source · first seen Jun 2026

Also counts toward: CSV data export

example

  • Audit a single binary for the full new check suite (SafeStack, sanitizers, W^X, stack-clash) and emit machine-readable CSV for ingestion into a spreadsheet or SIEM. checksec file /usr/bin/myapp --output csv 3.2.0 · Jun 2026 · source
Binary integrity verification shipped Verifies the integrity of binaries and scripts using digital signatures. 1 release · first seen Jun 2024

release

  • Adds cosign keyless signature support for verifying the integrity of binaries and scripts 2.7.1 · Jun 2024 · source · release history

Lines in monospace are the tool's own words: help text parsed from its source, or an endpoint from its API document. Under release, a line is our summary of a dated release. Under docs, it is quoted from the tool's own documentation or website. Each links back to the source it came from.

Score card

  1. Shipping velocity releases a month, last 12 months
  2. Documentation quality release-notes rubric, 0–100
  3. Breaking-change discipline how rarely a release breaks users, and notice given
  4. Maintenance risk quiet time against its own cadence, maintainers
  5. Innovation & surface new capabilities, API and MCP surface
  6. Community health
  7. Contributor trend distinct committers, this year against last
  8. Maintainer concentration bus factor now against a year ago
  9. Issue backlog trend issues closed per issue opened, 12 months
  10. Responsiveness median time to a maintainer’s first reply

Nine scores for checksec.sh, each built from the releases, notes and API history this site tracks — and, on Researcher and Business, where it stands among every measured tool in its category and how that has moved.

Score cards are part of every paid plan.

See plans →

Each score is 0–100 on a published rubric, derived from data this site already shows. A dimension we cannot measure says so — it is never scored 0 and never enters a rank.

How this is scored
  • Shipping velocity — releases a month over the last 12 months, on a log scale where 16 a month scores 100. Needs 3 releases in the window.
  • Documentation quality — the release-notes rubric published on the analytics page, unchanged.
  • Breaking-change discipline — the share of releases carrying a breaking change (none scores 100, half or more scores 0). Only projects that label breaking changes are measured: a clean record cannot be told from an unlabelled one.
  • Maintenance risk — quiet time measured against the tool's own release cadence (quiet longer than 90 days and three typical gaps scores 0), plus the number of active maintainers and whether contributors are growing, where known. Higher is lower risk.
  • Innovation & surface — new capabilities in the feature ledger this year, API and MCP operations added, and the share of commits that are features: the mean of whichever we hold.
  • Community health (open-source tools only) — each is a direction, not a size: contributors this year against last, the bus factor now against a year ago, and issues closed per issue opened, where steady scores 50, doubled 100 and halved 0; plus the median time to a maintainer's first reply (an hour scores about 100, a month or more 0). A commercial card has no repository and carries none of the four.
  • Documented delivery (commercial tools) — when a vendor's documented new capabilities have slowed against its own baseline, that counts against the overall standing as heavily as two low dimensions. Steady delivery, or too little history to judge, leaves the standing alone; it is never a sixth score.
  • Open-source tools are scored on repository signals; commercial tools on their published changelog. Ranks compare tools within one category and one profile and need at least five measured peers; the overall standing needs three ranked dimensions. Best-in-breed or consolidator is a shape, not a quality, and is never scored.

Release-note detail over time

See how much detail checksec.sh puts in its release notes, quarter by quarter, and compare it with tracked tools in the same category. This history uses up to ten retained, reviewed notes per tool; sparse or blank older quarters may reflect that limit.

Checking release-note history…

Explore the full chart →

Releases

Show

10 entries

  1. September 20264
  2. June 20262
  3. December 20251
  4. June 20241
  5. May 20201
  6. July 20191
    Show

    10 entries

    Project health

    Issue, contributor and maintainer activity in slimm609/checksec, 2023-10 – 2026-09, as of 2026-09-25. Twelve-month figures first; the trend lines run the whole window.

    1. Contributors 9 +4 vs prior 12 months
    2. Maintainers 2 +3 joined · −3 left, last 12 months
    3. Bus factor 1 committers behind half the commits
    4. Community-filed not measured of issues opened, last 12 months
    5. Median time to close not measured issues closed, last 12 months
    6. Open backlog not measured open issues today
    1. Issues opened / month not measured
    2. Open backlog not measured
    3. Contributors / month 1
    4. Commits / month 1
    5. Stars 2,384
    Issue themes, last 12 months not measured

    Counts from the project's public repository and git history; no individuals are identified. Maintainers are the committers covering 80% of the last year's commits. how we measure this

    Libraries its release ships

    What its latest release locks, checked against known advisories.

    None of its release's images build from a lockfile we can read.

    Add the badge to your README

    Maintain this project? The badge links readers straight to this page, so they can follow every release here.

    Tracked by Cyber Toolchain Choose a badge style and copy the code →
    browse all tools → score card for your toolchain →