A website's login session handling can be tricked by a specially crafted cookie into sending extra instructions to its cache server. This can let an attacker run commands the site never intended.

1. How it works:
2. Attacker crafts cookie
3. Request sent to site
4. CHI store builds cache key
5. Memcached reads extra commands
6. Attacker sends commands to cache server

Prefab UI's Generative UI feature runs code meant to be isolated, but the isolation can be bypassed. Someone who can send code to it can read and change files on the server and keep running code there.

1. How it works:
2. Attacker sends code
3. FastMCP server
4. Pyodide sandbox
5. Server files
6. Attacker runs code on the server

A customer with a normal login can reach files that belong to other customers on the same server, and can read and change them. The flaw comes from a missing check on which storage volume a deployment may attach.

1. How it works:
2. Tenant with token
3. Crafted volume ID
4. Path escapes root
5. Read-write mount
6. Attacker reads and writes other tenants' data

A tenant with a sandbox can use the file feature to read, change, or delete files on the shared server running their sandbox, including other customers' files. Attackers may be able to take over the whole cluster.

1. How it works:
2. Tenant holds sandbox
3. Sends crafted file path
4. Worker joins path unsafely
5. Host file accessed as root
6. Attacker may gain cluster-admin control

A customer who submits a container image build can break out of the build's sandbox and reach files on the build machine. Those files include the machine's access token, which could be used against the rest of the system.

1. How it works:
2. Tenant submits image build
3. Shell command becomes RUN step
4. Build reaches worker filesystem
5. Worker credentials exposed
6. Tenant reads worker's service account token

A data-parsing library used by some Java programs can be tricked into going around in an endless loop while reading malicious input, which can freeze or crash the program. Upgrading the library fixes it.

1. How it works:
2. Attacker sends crafted data
3. Request reaches service
4. skip() recurses without limit
5. Service stalls or crashes
6. Java service becomes unavailable

The mtools tool, which reads and writes files on DOS-style (FAT) disks, can write data past the end of a memory area. This memory error can make the program misbehave.

A login library could let someone sign in as another person. An attacker can edit a form field during Apple login so the app believes it is a different user.

1. How it works:
2. Attacker signs in
3. Attacker edits user field
4. Library merges data
5. App trusts wrong identity
6. Attacker logs in as another user

Anyone on the network can claim the administrator account of this Okta helper tool before the real owner finishes setup. The attacker then controls the tool and the Okta data it reads.

1. How it works:
2. Attacker scans network
3. Calls setup endpoint
4. Admin account created
5. Okta data accessed
6. Attacker controls the admin account

A specially built, broken PDF file can make the pypdf Python library freeze instead of finishing its work. Anything that opens such a file can get stuck waiting, which can block a service.

1. How it works:
2. Attacker crafts PDF
3. App opens the file
4. pypdf searches trailer
5. Thread blocks forever
6. Processing thread hangs indefinitely

A small, specially crafted zip or tar.gz file uploaded as a pipeline can expand into a huge amount of data in the server's memory, which can slow or crash the service. Uploads can be processed before permission checks, so unauthorized calle

1. How it works:
2. Crafted archive
3. Upload request
4. Server decompresses
5. Memory exhausted
6. API server service is interrupted

Someone who can reach the Kubeflow Pipelines backend and knows a run ID can read that run's logs, which may contain private data or passwords. Live logs can also be pulled from an unrelated pod in the same namespace.

1. How it works:
2. Attacker with access
3. Knows a run ID
4. Log request sent
5. Logs returned
6. Attacker reads another run's logs

A specially crafted PDF file can make the pypdf Python library use a huge amount of memory, which can slow down or crash the program reading it. Opening untrusted PDFs is the main risk.

A specially crafted PDF file can make the pypdf Python library get stuck in an endless loop, freezing the program that processes it. Nothing in the material says data is stolen or systems are taken over.

1. How it works:
2. Attacker crafts PDF
3. Application processes file
4. pypdf traverses cycle
5. Process hangs
6. Processing hangs, service becomes unavailable

A specially crafted upload with a very long header value can make a Node.js server stop responding for a long time. Anyone who can send a request to the server can do this without logging in.

1. How it works:
2. Attacker sends upload
3. Request reaches server
4. Header parsed
5. Event loop blocked
6. Server stops responding to users

A single crafted request with a very long run of spaces can make a Node.js server stop responding for several seconds. Other users' requests wait during that time.

1. How it works:
2. Attacker sends request
3. Route validates field
4. Regex backtracks
5. Event loop blocked
6. Server stops responding for seconds

A specially crafted glob pattern (a file-matching pattern) can make the minimatch library use huge amounts of CPU and memory while it prepares the pattern, which can slow down or crash the app using it.

1. How it works:
2. Crafted pattern
3. Pattern compiled
4. Expansion loop
5. Pairwise comparison
6. Service slows down or crashes

A specially crafted, broken PDF file can make the pypdf Python library use huge amounts of memory while it reads the file. This can slow down or crash the program that opens it.

1. How it works:
2. Attacker sends PDF
3. App parses file
4. Errors balloon
5. Memory exhausted
6. Service memory exhaustion, possible crash

A specially crafted PDF file can make the pypdf Python library run extremely slowly when it reads page labels. This can tie up a program or server for a long time.

1. How it works:
2. Crafted PDF
3. App reads labels
4. Repeated scans
5. Slow processing
6. Program or server becomes unresponsive

A client holding its own valid access token could read, change, or delete a different client's registration. Changing redirect addresses could let an attacker steal login codes or tokens.

1. How it works:
2. Attacker holds token
3. Sends request
4. Missing ownership check
5. Registration changed
6. Other clients' registrations are hijacked or removed

A specially crafted encrypted PDF file can make the pypdf Python library slow down a lot or use up a lot of memory when it reads the page count. This can freeze or crash a program that opens untrusted PDF files.

1. How it works:
2. Attacker crafts PDF
3. PDF reaches application
4. App reads page count
5. Excessive work
6. Service slows down or crashes

A specially crafted PDF file can make the pypdf Python library use up huge amounts of memory and slow or crash the program that opens it. Opening an untrusted PDF is the main risk.

1. How it works:
2. Attacker crafts PDF
3. PDF is delivered
4. pypdf opens file
5. Memory exhausted
6. Service slows down or crashes

A crafted number inside data sent to the pyasn1 library can make a program freeze or run very slowly while it reads that data. Someone could use this to keep a server busy, which can make it unresponsive to other users.

1. How it works:
2. Crafted input
3. App decodes data
4. CPU busy
5. Service slows
6. Availability loss from CPU exhaustion

pyasn1 is a Python library that reads a common data format used in certificates and security messages. A specially built input made of many small pieces can make it take a very long time to read, which can freeze the program that is reading

1. How it works:
2. Attacker crafts input
3. Input reaches app
4. pyasn1 decodes it
5. CPU exhausted
6. Decoding thread stalls, denial of service

Someone can send a specially built block of data that makes a program using pyasn1 spend a lot of processing time on it. Enough of these can tie up the server's CPU and slow or stop the service.

1. How it works:
2. Attacker sends data
3. Request reaches app
4. pyasn1 decodes
5. CPU saturates
6. Service slows down or stops responding

A specially crafted small piece of data can make programs that read certain security-related data formats use a lot of processor time. This can slow down or stall the service reading it.

1. How it works:
2. Attacker sends crafted data
3. Data reaches the service
4. Decoder slows down
5. CPU is exhausted
6. Service becomes slow or unavailable

Someone can send a specially crafted certificate or key text that makes a Node.js app hang for a long time while it tries to read it. This is a denial-of-service issue: the app stops responding but no data is stolen.

1. How it works:
2. Attacker sends PEM
3. App parses input
4. Event loop blocked
5. Service unresponsive
6. Application becomes unresponsive (denial of service)

A flaw in the node-forge JavaScript library can make it trust a certificate that should not be trusted as a certificate authority. A holder of such a certificate could then create fake certificates for any website, which can fool apps into

1. How it works:
2. Obtains certificate
3. Forges extension
4. Verification passes
5. Impersonation
6. Attacker impersonates servers or clients

A remote computer can send a few specially crafted bytes to a Node.js program using this TLS library, which makes the whole program crash. No login is needed to trigger it.

1. How it works:
2. Remote peer
3. Split handshake
4. process() call
5. Uncaught TypeError
6. Node.js process crashes

A remote computer that connects to your app can send one burst of many tiny messages and make the program crash. The crash stops the service until it restarts.

1. How it works:
2. Malicious peer
3. Burst of records
4. node-forge recursion
5. Stack overflow
6. Service goes down until restarted

Attackers can craft a fake certificate file (PKCS#12) that opens with any password, or decrypt a private key without knowing its password. This can let them tamper with files or read keys they should not see.

1. How it works:
2. Attacker crafts file
3. node-forge derives key
4. App accepts file
5. Forged content trusted
6. Attacker bypasses password checks

When this library uploads a file to a container registry, it can accidentally send the login token or password to another website if the registry points it there. Someone running a hostile or hacked registry could collect those credentials.

1. How it works:
2. Hostile registry
3. Upload redirect
4. Client PUTs blob
5. Credentials captured
6. Attacker obtains registry credentials

A popular Node.js library can accidentally send your custom secret header (like an API key) to a different website when the server redirects. Built-in login headers stay protected; only custom ones are at risk.

1. How it works:
2. Attacker controls endpoint
3. App sends request
4. Library follows redirect
5. Header forwarded
6. Attacker receives your custom API key

A short, specially crafted GraphQL request can make the server keep growing its memory use, and each repeated request adds more. A busy server can eventually run out of memory and crash, but no data is stolen or changed.

1. How it works:
2. Attacker
3. Validation runs
4. Shared error reused
5. Memory grows
6. Worker runs out of memory and crashes

Keys added to the SSH agent with the 'ask me first' option (ssh-add -c) can be used without asking the user. Anyone who can reach the agent socket, including a remote host you forwarded your agent to, may sign in as you.

1. How it works:
2. Process with socket access
3. Requests a signature
4. Agent skips confirmation
5. Never prompted
6. Attacker signs or logs in as the user

A client app with limited permissions can sometimes pretend to be a more powerful app during token requests. This can let it obtain access it should not have.

1. How it works:
2. Low-privilege client
3. Token request
4. OAuthlib authenticates
5. Wrong identity checked
6. Attacker gets unauthorized access tokens