Security fixes are applied only to the latest released version. Users are strongly encouraged to upgrade.

Please report security vulnerabilities via GitHub Security Advisories.

Do not open public issues for security-related reports.

When reporting, include:

• Affected versions
• Detailed reproduction steps
• Proof-of-concept (if available)
• Impact assessment

• Initial acknowledgment: within 48 hours
• Triage and assessment: within 3–5 days

• Critical issues: < 7 days
• High severity: < 14 days
• Medium/Low: best effort

• Critical

  • Arbitrary code execution through instrumentation
  • Unsafe class loading leading to sandbox escape

• High

  • Privilege escalation via agent misuse
  • Bypassing intended constraints in bytecode generation

• Medium

  • Denial of service via malformed bytecode
  • Stability issues impacting runtime safety

• Low

  • Edge-case validation issues
  • Non-exploitable incorrect behavior

• Vulnerabilities are handled via private coordination
• Fixes are developed and validated before disclosure
• Public disclosure occurs after a fix is available

Advisories will include:

• Affected versions
• Description of impact
• Mitigation steps
• Upgrade guidance

• Incidents may be identified through vulnerability reports, dependency alerts, or community reports
• All reports received via GitHub Security Advisories are treated as potential incidents

• The maintainer evaluates severity using the classification above
• Critical and High issues are prioritized immediately
• Affected versions and attack surface are determined

• If a released artifact is compromised, affected versions are flagged in the advisory
• Users are directed to pin a known-safe version or disable the affected feature (e.g., detaching a Java agent)

• A fix is developed and validated in a private branch
• The fix is released as a new version on Maven Central
• The GitHub Security Advisory is updated with the fixed version and mitigation steps

• Users are notified through the GitHub Security Advisory
• Critical issues may also be announced via release notes and the project README

• The root cause and timeline are documented in the advisory
• Process improvements are applied to prevent recurrence

• Restrict use of Java agents in production environments
• Validate class loaders and transformation targets
• Keep Byte Buddy updated to the latest version
• Avoid exposing instrumentation capabilities to external users

Byte Buddy repackages ASM internally to avoid dependency conflicts.

Users should still monitor:

• JVM-level vulnerabilities
• Build and runtime environments
• Dependency scanning results in their own systems

Byte Buddy is safe to use as a regular library for class generation and extension when used within trusted code. The primary risks arise from features that allow modification of existing code or execution of injected logic.

Java agents can transform or redefine classes at runtime and operate with the full privileges of the hosting JVM.

Risks

• Injection of arbitrary code into application classes
• Modification of security-sensitive logic
• Full process compromise if misused or exposed

Guidance

• Do not allow untrusted agents
• Restrict agent attachment in production environments

Byte Buddy can be used in build tools to modify bytecode during compilation or packaging.

Risks

• Execution of malicious code during build
• Supply chain compromise via untrusted plugins or dependencies

Guidance

• Only use trusted plugins and dependencies
• Verify build integrity and dependency sources

• Regular library usage is considered safe under normal conditions
• The main security risks stem from code injection capabilities, especially via agents and build-time instrumentation