Intro

At the end of last year and the beginning of this one, I focused on IBM i library list (LIBL) based privilege escalation vulnerabilities — a subtle but critical class of issues that can quietly undermine the security of both the core operating system and 3rd party applications. While many administrators assume adopted authority and object ownership are “handled” by default, our research and real world pentests have shown otherwise: insecure program placement and weak library list management still open the door to serious privilege escalation.

To help raise awareness and accelerate remediation, I’m releasing two automation tools: The Privilege Escalation Checker identifies vulnerable program objects by combining system provided SQL views with OS command output, giving defenders a clear picture of their exposure. Building on that, the Automated Exploitation Module demonstrates how attackers can turn those findings into working exploits — automatically testing execution paths, manipulating parameters, and generating a new *OWNER command program.

By publishing these tools, my goal is not to hand attackers another weapon but to push both IBM and IVS vendors to eliminate this entire vulnerability class once and for all. The scripts were tested on 7.4, 7.5.

Privilege Escalation Checker (p.sh)

This is a quite simple application it collects the possible candidates based on the command line parameters:

===============================================
IBM i *LIBL Based Privilege Escalation Scanner
Silent Signal | https://ibmi.silentsignal.eu
===============================================

Usage: ./p.sh [-l LIBRARY] [-u USER_PROFILE] [-h]

Options:
  -l LIBRARY       Specify the library (default: '*ALL')
  -u USER_PROFILE  Specify the user profile (default: '*PUBLIC')
  -h               Show this help message

Most of the time, running the scanner with no command line parameters is the best way to cover the entire IBM i system. You can also specify a target library and user profile to narrow the scope. This version does not yet support Authorization Lists (AUTL); if you need that, you can easily extend it by adding the appropriate view to the SQL query.

Let’s assume administrators have installed all PTFs and believe the system is protected against privilege escalation, but the machine also runs a few 3rd party applications. That’s where the real gold mine of vulnerabilities tends to be. Don’t believe me? Check your system. In our last two pentests, we identified 1324 and 474 candidates among program objects that could enable horizontal or vertical privilege escalation. In my experience, even if the well-known profile swapping issues are mitigated, privilege escalation can be achieved through libl abuse.

Automated Exploitation Module (e.sh)

This scipt is the real deal:

================================================
IBM i *LIBL Based Privilege Escalation Exploiter
Silent Signal | https://ibmi.silentsignal.eu
================================================
Usage: ./e.sh -u OWNER -p PGM -s "SUBPGM1,SUBPGM2,..."
  -u    Owner of the vulnerable PGM (required)
  -p    The vulnerable PGM (required)
  -s    Comma-separated list of sub-PGMs (required; Example: -s "PGMA,PGMB")
  -l    Work library for sources and shells
  -h    Show this help message

Based on the output of p.sh, e.sh needs the OWNER attribute of the vulnerable program object. This value is used by the script to validate the result after the exploitation attempt. Specify the vulnerable program object in LIBRARY/PROGRAM format, and list the called/sub program objects. You must also configure a working library to which you have write access, because the script creates multiple objects there. If this library is not present, the script will create it.

By default, the script calls the vulnerable PGM using a modified library list, and brute forces the correct number of parameters. If exploitation succeeds, the script creates a CL command runner program object for interactive command execution, running with the vulnerable program’s owner privileges.

Here is a video that demonstrates the discovery and exploitation of CVE-2025-36004 using p.sh and e.sh:

Countermeasures

*LIBL based escalation usually depends on two things: resolving objects through the library list, and overly broad authorities. These countermeasures aim to remove *LIBL from sensitive lookups, reduce or eliminate adoption, and set safe defaults, so user-controlled settings can’t affect trusted code. Used together, they close easy privilege escalation paths while keeping normal operations intact.

Use Authorization Lists and/or set *PUBLIC to *EXCLUDE

If users don’t need to run a program, they should not be able to do so. Apply an authorization list to the vulnerable program objects or remove unnecessary *PUBLIC *EXECUTE from those PGMs. This blocks casual invocation paths and reduces the chance that user-controlled contexts can reach the exploitable ones. Grant only the minimum execution rights required to specific groups or service profiles.

Minimize or remove adoption

Adopted authority should be the exception, not the rule. Prefer programs that run with the caller’s authority (USRPRF(*USER)) and reserve adoption for narrowly-defined cases with clear business justification. If adoption is unavoidable, follow the safeguards above to prevent unauthorized access.

Fully qualify every sensitive call (never rely on *LIBL)

Fully qualify programs, service programs, commands, procedures, and tables, so resolution is deterministic and independent of the user’s library list. Where possible, prefer static binding to service programs, so name resolution occurs at build time rather than at runtime. Once qualification is universal for sensitive paths, manipulating *LIBL stops being a viable escalation vector.

Library list

Keep trusted libraries in the portions of the library list that precede the user-modifiable segment. Use consistent initial library lists through job descriptions and sign-on flows to avoid malicious states. Restrict who can change global job settings or introduce new libraries into production. Most importantly, ensure that writable or user-controlled libraries are never part of the trusted search path by policy.

Outro

It’s important to note that this privilege escalation technique doesn’t apply universally. In the case of GUI-driven programs, automated exploitation with e.sh usually doesn’t work — escalation has to be attempted manually. In addition, some programs may drop adopted authority during execution or manipulate the library list at runtime — we observed this couple of times in real-life systems. Both behaviors can override the tester’s setup and break the escalation chain, preventing privilege escalation altogether.

These defensive behaviors highlight that privilege escalation through LIBL mismanagement is not always a guaranteed path — but the fact that it works at all in many real world cases makes it a serious systemic risk. Attackers only need one exploitable program path with retained authority to succeed, while defenders must ensure that every program, in every library list context, is hardened. These scripts at least eliminate the low hanging fruit and can be extended further to exploit more advanced scenarios.

P.S.: If you think that blocking the specific implementation of the p.sh and e.sh scripts will prevent exploitation, keep in mind that there are many other ways to collect the necessary information and exploit the weakness.

The tools are in our GitHub repository.