AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 37 Monero

Add subaddress support check

Public commit record

What the developer wrote

Authored by Keeqler

35/100 · Opaque
Add subaddress support check
✓ Descriptive subject! No meaningful explanatory body! Opaque security-relevant change
The short version

What changed, and why it matters

This commit adds a feature that checks whether the user's chosen Monero light-wallet server supports subaddresses. Before this change, the app could show a subaddress even when the server did not support it, which could cause incoming transactions to be missed. The change also removes a stored user preference that always defaulted to showing the primary address, and instead auto-detects server capability and defaults to showing a subaddress when supported. The most notable security-relevant side effect is that the app now sends the wallet's secret view key to the light-wallet server during the check, and it does so over plain HTTP unless the user has enabled SSL/Tor. That is a privacy-sensitive design choice, but it is consistent with how Monero light wallets already operate.

Recommended action

Treat this as a privacy-hardening review item rather than an urgent vulnerability. Verify that the /upsert_subaddrs endpoint and payload are consistent with the expected light-wallet server API, add response parsing/validation rather than relying only on status code 200, ensure the view key is never logged (the diff hides it, which is good), and consider warning users when connecting to a server over plain HTTP. Review whether a malicious server returning 200 can trick the wallet into defaulting to subaddresses while not actually indexing them, causing funds to be harder to recover.

Security signals we found

01

Secret view key transmitted to remote light-wallet server during capability probe

02

Probe uses http/https depending on user SSL setting; no mandatory encryption

03

Capability determined solely by HTTP 200 status, which a malicious or compromised server can fake

04

Default receive address changed from primary to subaddress when server claims support

05

Tor/SOCKS HTTP helper previously dropped request body; now correctly serializes body

06

No commit message or code comments describing this as a security fix

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 5/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.