CWE-319 Base Draft High likelihood

Cleartext Transmission of Sensitive Information

This vulnerability occurs when an application sends sensitive data, such as passwords or personal information, over a network connection without using encryption. Attackers can easily intercept and…

Definition

What is CWE-319?

This vulnerability occurs when an application sends sensitive data, such as passwords or personal information, over a network connection without using encryption. Attackers can easily intercept and read this unprotected data as it travels.
When data is transmitted in cleartext, it's like sending a postcard instead of a sealed letter—anyone handling it can read the contents. This is a fundamental security failure because modern networks, especially public Wi-Fi, are shared environments where attackers use simple 'sniffing' tools to capture traffic. Sensitive information like login credentials, session tokens, financial details, or personal data should never be exposed this way. The solution is to always use strong encryption for all communication channels. This means enforcing HTTPS (TLS/SSL) for web traffic and encrypted protocols like SSH or VPNs for other connections. Developers should implement encryption by default, avoid mixed content (HTTP within HTTPS pages), and use security headers like HTTP Strict Transport Security (HSTS) to prevent accidental cleartext transmission.
Vulnerability Diagram CWE-319
Cleartext Transmission Client http://… (no TLS) Public Wi-Fi / ISP POST /login user=alice&pw=hunter2 Cookie: session=abc Server sniffer Anyone on the path reads or rewrites credentials and tokens.
Real-world impact

Real-world CVEs caused by CWE-319

  • Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.

  • Building Controller uses a protocol that transmits authentication credentials in plaintext.

  • Programmable Logic Controller (PLC) sends password in plaintext.

  • Passwords transmitted in cleartext.

  • Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.

  • Product sends password hash in cleartext in violation of intended policy.

  • Remote management feature sends sensitive information including passwords in cleartext.

  • Backup routine sends password in cleartext in email.

How attackers exploit it

Step-by-step attacker path

  1. 1

    The following code attempts to establish a connection to a site to communicate sensitive information.

  2. 2

    Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

  3. 3

    In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

  4. 4

    Multiple vendors used cleartext transmission of sensitive information in their OT products.

  5. 5

    A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed.

Vulnerable code example

Vulnerable Java

The following code attempts to establish a connection to a site to communicate sensitive information.

Vulnerable Java
try {
  	URL u = new URL("http://www.secret.example.org/");
  	HttpURLConnection hu = (HttpURLConnection) u.openConnection();
  	hu.setRequestMethod("PUT");
  	hu.connect();
  	OutputStream os = hu.getOutputStream();
  	hu.disconnect();
  }
  catch (IOException e) {
```
//...* 
  	}
Secure code example

Secure Shell

Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as:

Secure Shell
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-319

  • Architecture and Design Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.
  • Implementation When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.
  • Implementation When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.
  • Testing Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
  • Operation Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
Detection signals

How to detect CWE-319

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

Automated Static Analysis High

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

CWE-319

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Frequently asked questions

Frequently asked questions

What is CWE-319?

This vulnerability occurs when an application sends sensitive data, such as passwords or personal information, over a network connection without using encryption. Attackers can easily intercept and read this unprotected data as it travels.

How serious is CWE-319?

MITRE rates the likelihood of exploit as High — this weakness is actively exploited in the wild and should be prioritized for remediation.

What languages or platforms are affected by CWE-319?

MITRE lists the following affected platforms: Cloud Computing, Mobile, ICS/OT, System on Chip, Test/Debug Hardware.

How can I prevent CWE-319?

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols. When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

How does Plexicus detect and fix CWE-319?

Plexicus's SAST engine matches the data-flow signature for CWE-319 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-319?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/319.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)