Log inLog in

Base weakness

Incomplete

CWE-487: Reliance on Package-level Scope

Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

Last updated May 1, 2026

0

Recorded CVEs

With this primary weakness

0

KEVs

In the CISA KEV catalog

Medium

Likelihood of exploit

Per MITRE

Base

Abstraction

MITRE classification

Overview

The purpose of package scope is to prevent accidental access by other parts of a program. This is an ease-of-software-development feature but not a security feature.

Common consequences

What can happen when CWE-487 is exploited.

Read Application Data

Affects: Confidentiality

Any data in a Java package can be accessed outside of the Java framework if the package is distributed.

Modify Application Data

Affects: Integrity

The data in a Java class can be modified by anyone outside of the Java framework if the package is distributed.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

Applies to

Languages

Java

How to prevent it

Practical mitigations for CWE-487, grouped by where in the lifecycle they apply.

Architecture and Design

Implementation

Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering.

How to detect it

Automated Static Analysis

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.)

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

The following example demonstrates the weakness.

Vulnerable example

java

package math;

Terminology & mappings

Mapped taxonomies

CLASP: Relying on package-level scope
The CERT Oracle Secure Coding Standard for Java (2011): Do not increase the accessibility of overridden or hidden methods (MET04-J)

Frequently asked questions

Common questions about CWE-487.

What is CWE-487?

Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

How do you prevent CWE-487?

Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering.

How is CWE-487 detected?

Automated Static Analysis: 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.)

What are the consequences of CWE-487?

Exploiting CWE-487 can lead to: Read Application Data, Modify Application Data.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Stay ahead of CWE-487

Get alerted the moment a new CWE-487 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.

Start free See pricing