Wso2 Security Scan

WSO2 Product Security Vulnerability Scan Skill

When to Use

• CVEs or GHSAs from a Docker image security scan (Trivy, Grype, Snyk, or similar SCA tools).
• Security advisories or threat intel notices without a CVE number (e.g. supply chain compromises, hijacked packages, zero-days, vendor bulletins).
• You need to locate a vulnerable component inside a WSO2 IS runtime — whether a Docker image, a local product distribution, or a deployed installation.
• You need to assess whether a reported issue is actually present and exploitable in the context of WSO2 IS.

Determining the Scan Target

WSO2 IS can be scanned in two ways depending on what is available:

Always prefer scanning the local runtime if it is available — it reflects the exact deployed state. Ask the user for the WSO2_IS_HOME path before pulling a Docker image unnecessarily.

Step 1 — Identify the Vulnerability Type

Before searching, classify what you are looking for. This determines the search strategy.

For advisories without a CVE, extract the key facts from the notice: affected package name, affected versions, and any indicator of compromise (IOC) paths or file names provided.

Step 2 — Access the Runtime

Option A — Local distribution (preferred)

If the user provides a path, use it directly as WSO2_IS_HOME. No Docker pull needed.

Option B — Docker image

WSO2 Docker images are hosted at registry.wso2.com. You need a CLI Secret from the WSO2 Support Portal:

Support Portal → Projects → My Projects → Registry Tokens → Generate Token

Read credentials from the .env file, then login:

docker login registry.wso2.com -u '<WSO2_email>' -p '<CLI_Secret>'
docker pull registry.wso2.com/wso2-is/is:<version>-alpine-jdk8

Step 3 — Locate the Vulnerable Component

Java library CVE — Direct JAR search

find <WSO2_IS_HOME> -name "*<library>*" 2>/dev/null | sort

Java library CVE — Nested JAR search (jar-in-jar — always run this)

SCA scanners detect JARs embedded inside OSGi bundles. A pom.xml text search alone misses these because the nested JAR may not be declared as a Maven dependency in the outer JAR's pom.

find <WSO2_IS_HOME> -name "*.jar" | while read jar; do
  jar tf "$jar" 2>/dev/null | grep -i "\.jar$" | while read nested; do
    echo "$jar → $nested"
  done
done | grep -i "<library>"

Real example: zookeeper-3.9.4.jar is embedded inside solr_8.11.1.wso2v18.jar at repository/components/plugins/. It does not appear as a standalone file anywhere in the image.

Go binary vulnerability (stdlib CVEs)

The bin/wso2update_linux binary is the WSO2 U2 Update Tool, compiled with Go. Go stdlib CVEs (e.g. net/url, crypto/tls) will be flagged against this binary:

go version -m <WSO2_IS_HOME>/bin/wso2update_linux 2>/dev/null | grep "^go"

This binary is not a runtime service — it only runs during administrator-initiated update windows.

NPM / JavaScript supply chain advisory (CVE or no CVE)

WSO2 IS 5.11.0 is a Java application and does not use NPM at runtime. However, the React-based Console and MyAccount webapps ship pre-compiled webpack bundles that may embed JavaScript libraries. Check:

1. Is NPM used at all in the distribution?

# No node_modules or lock files = npm never ran here; bundled JS only
find <WSO2_IS_HOME> -type d -name "node_modules" 2>/dev/null
find <WSO2_IS_HOME> -type f \( -name "package.json" -o -name "package-lock.json" \
  -o -name "yarn.lock" -o -name "pnpm-lock.yaml" \) 2>/dev/null

2. Do the affected package/version strings appear in the distribution?

grep -r "<package-name>" <WSO2_IS_HOME> --include="*.json" \
  --include="*.yaml" --include="*.lock" -l 2>/dev/null
# Also check bundled JS chunks for exact version strings
grep -r "<affected-version>" <WSO2_IS_HOME> --include="*.js" 2>/dev/null | head -20

3. Check for IOC artifacts on disk (paths provided in the advisory):

# Example for a macOS RAT dropper — substitute paths from the advisory
ls -la /Library/Caches/<artifact> 2>/dev/null && echo "COMPROMISED" || echo "clean"
ls -la /tmp/<artifact> 2>/dev/null && echo "COMPROMISED" || echo "clean"

Key point: If no node_modules directory and no lock files exist in the distribution, and the malicious version string does not appear literally in any bundled JS file, the installation is not affected — WSO2 did not run npm install with a compromised package. Check the bundle file timestamps against the attack window as a final confirmation.

Step 4 — Assess Actual Exploitability

Known Component Locations for Common SCA Hits