Insecure RNG (java.util.Random) in sampling code triggers compliance failures in security audits (4.1.2.3.6敏感性資料應採用適當且有效之金鑰長度與加密演算法，進行加密處理再儲存)

[sultanmyrza]

Hello Facebook Android SDK team,

We are using the Facebook Android SDK in our app, and it is failing a third-party security audit (4.1.2.3.6 敏感性資料應採用適當且有效之金鑰長度與加密演算法，進行加密處理再儲存) due to usage of insecure random number generators.

Specific finding (from decompilation via jadx-gui and Semgrep rule mastg-android-random-apis-insufficient-entropy):

facebook-android-sdk/facebook-core/src/main/java/com/facebook/FacebookException.kt

Lines 28 to 39 in 1b75585

	if (message != null && FacebookSdk.isInitialized() && rand.nextInt(100) > 50) {
	checkFeature(FeatureManager.Feature.ErrorReport) { enabled ->
	if (enabled) {
	try {
	save(message)
	} catch (ex: Exception) {
	/*no op*/
	}
	}
	}
	}
	}

Breakdown of the Finding:

• File: com.facebook.FacebookException.java (from Facebook Android SDK, detected via decompilation)
• Rule: mastg-android-random-apis-insufficient-entropy (OWASP MASTG-derived Semgrep rule)
• MASVS Reference: [MASVS-CRYPTO-1] - requires strong cryptography and sufficient entropy for crypto-related operations
• Issue: rand is an instance of java.util.Random (weak PRNG with insufficient entropy), and rand.nextInt(100) is used for conditional sampling (likely error reporting throttling or debug logging)
• Why flagged: Auditors require all RNG usage in the APK to use cryptographically secure sources (e.g., SecureRandom, NIST SP 800-90A compliant) when evaluating encryption-related criteria — even if the specific usage is non-crypto

Context:

• This line appears to be for lightweight random sampling (e.g., throttling logs, error reporting probability), not for cryptographic key/IV/nonce generation.
• However, strict audits (common in Taiwan, government/finance sectors) fail the entire app if any java.util.Random or Math.random() appears in the binary, without deep context analysis.
• We cannot patch the SDK ourselves, and upgrading to the latest version (18.x as of Jan 2026) did not remove this pattern (based on our testing).

Our Concerns and Questions:

• We're concerned that this pattern is blocking compliance/certification for our app, even though the usage appears to be non-cryptographic.
• What is the Facebook team's position on using java.util.Random in SDK code for non-crypto purposes? Is this considered acceptable, or are there plans to migrate to SecureRandom?
• How should developers handle this situation when facing strict security audits that flag all RNG usage regardless of context?
• If this has already been addressed in a recent or upcoming version, could you point us to the relevant changelog or commit?

This appears to be a low-severity issue in practice (no real security risk from sampling), but it's blocking certification/compliance for our app and potentially others in regulated markets.

We'd appreciate the team's guidance on how to proceed and understand your perspective on this matter.

Thank you!

Best regards

Checklist before submitting a bug report

• I've updated to the latest released version of the SDK
• I've searched for existing Github issues
• I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group
• I've read the Code of Conduct
• This issue is not security related and can safely be disclosed publicly on GitHub

Java version

21.0.8

Android version

API 23, Android 11

Android SDK version

36.0.2-14143358

Installation platform & version

Gradle 8.7

Package

Core & AppEvents

[taado225-dev]

Skip to content
Navigation Menu
Sign in
https://github.com/facebook
/
facebook-android-sdk
Public
Code
Issues
147
Insecure RNG (java.util.Random) in sampling code triggers compliance failures in security audits (4.1.2.3.6敏感性資料應採用適當且有效之金鑰長度與加密演算法，進行加密處理再儲存) #1380
Open
Open
Insecure RNG (java.util.Random) in sampling code triggers compliance failures in security audits (4.1.2.3.6敏感性資料應採用適當且有效之金鑰長度與加密演算法，進行加密處理再儲存)
#1380
Labels
bug
needs-triage
Jump to bottom
Description
@sultanmyrza
sultanmyrza
opened 2 weeks ago · edited by sultanmyrza
Hello Facebook Android SDK team,

We are using the Facebook Android SDK in our app, and it is failing a third-party security audit (4.1.2.3.6 敏感性資料應採用適當且有效之金鑰長度與加密演算法，進行加密處理再儲存) due to usage of insecure random number generators.

Image Image
Specific finding (from decompilation via jadx-gui and Semgrep rule mastg-android-random-apis-insufficient-entropy):

facebook-android-sdk/facebook-core/src/main/java/com/facebook/FacebookException.kt

Lines 28 to 39 in 1b75585

if (message != null && FacebookSdk.isInitialized() && rand.nextInt(100) > 50) {
checkFeature(FeatureManager.Feature.ErrorReport) { enabled ->
if (enabled) {
try {
save(message)
} catch (ex: Exception) {
/no op/
}
}
}
}
}
Breakdown of the Finding:

File: com.facebook.FacebookException.java (from Facebook Android SDK, detected via decompilation)
Rule: mastg-android-random-apis-insufficient-entropy (OWASP MASTG-derived Semgrep rule)
MASVS Reference: [MASVS-CRYPTO-1] - requires strong cryptography and sufficient entropy for crypto-related operations
Issue: rand is an instance of java.util.Random (weak PRNG with insufficient entropy), and rand.nextInt(100) is used for conditional sampling (likely error reporting throttling or debug logging)
Why flagged: Auditors require all RNG usage in the APK to use cryptographically secure sources (e.g., SecureRandom, NIST SP 800-90A compliant) when evaluating encryption-related criteria — even if the specific usage is non-crypto
Context:

This line appears to be for lightweight random sampling (e.g., throttling logs, error reporting probability), not for cryptographic key/IV/nonce generation.
However, strict audits (common in Taiwan, government/finance sectors) fail the entire app if any java.util.Random or Math.random() appears in the binary, without deep context analysis.
We cannot patch the SDK ourselves, and upgrading to the latest version (18.x as of Jan 2026) did not remove this pattern (based on our testing).
Our Concerns and Questions:

We're concerned that this pattern is blocking compliance/certification for our app, even though the usage appears to be non-cryptographic.
What is the Facebook team's position on using java.util.Random in SDK code for non-crypto purposes? Is this considered acceptable, or are there plans to migrate to SecureRandom?
How should developers handle this situation when facing strict security audits that flag all RNG usage regardless of context?
If this has already been addressed in a recent or upcoming version, could you point us to the relevant changelog or commit?
This appears to be a low-severity issue in practice (no real security risk from sampling), but it's blocking certification/compliance for our app and potentially others in regulated markets.

We'd appreciate the team's guidance on how to proceed and understand your perspective on this matter.

Thank you!

Best regards

Checklist before submitting a bug report

I've updated to the latest released version of the SDK

I've searched for existing Github issues

I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group

I've read the Code of Conduct

This issue is not security related and can safely be disclosed publicly on GitHub
Java version
21.0.8

Android version
API 23, Android 11

Android SDK version
36.0.2-14143358

Installation platform & version
Gradle 8.7

Package
Core & AppEvents

Activity

sultanmyrza
added
needs-triage

bug
2 weeks ago

mangod12
added a commit that references this issue last week
Security: Fix insecure RNG usage for compliance

d8ef889
https://github.com/apps/copilot-swe-agent
mentioned this last week
Security: Replace java.util.Random with SecureRandom for compliance mangod12/facebook-android-sdk#1

mangod12
mentioned this last week
Security: Fix insecure RNG usage for compliance (#1380) mangod12/facebook-android-sdk#2
to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Assignees
No one assigned
Labels
bug
needs-triage
Type
No type
Projects
No projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Participants
@sultanmyrza
Issue actions
Footer
© 2026 GitHub, Inc.
Footer navigation
Terms
Privacy
Security
Status
Community
Docs
Contact
Manage cookies
Do not share my personal information