Bug Bounty Policy

Last updated 2026-07-22

Wallbox builds the software and infrastructure behind electric vehicle charging, from our public web properties to the systems that talk to chargers in the field. We rely on independent security researchers to help us find weaknesses before they reach our customers, and this policy explains how to work with us, what we consider in scope, and how we reward the reports that help us the most.

Reporting a vulnerability

Send your report to security@wallbox.com in plain text. Screenshots and screen recordings are welcome as attachments, but the report body itself should not be a PDF or a DOCX — we will ask you to resend it in plain text if it is, since that's what lets our team triage quickly and act on your report without extra back and forth.

A good report includes clear, reproducible steps and the exact data you used to reproduce the issue. Reports that describe impact in the abstract, without a working reproduction, are much harder for us to act on and to reward fairly.

Once we receive your report, you can expect a first response within 5 business days of submission. From there, we'll keep you posted as we work through confirming the issue, fixing it, and deciding on a reward — timelines for those steps vary with severity and complexity, but we won't leave you without an update.

Scope

The following targets are in scope for this program:

• Web properties under *.wallbox.com, including the wallbox.com apex domain, with the exception of support.wallbox.com
• Our API backend, under *.wall-box.com
• The Wallbox iOS app, latest released version only
• The Wallbox Android app, latest released version only

Charger firmware and onboard software, and charger hardware, are not in scope for this program. If you believe you've found a vulnerability affecting a charger itself, please still report it to security@wallbox.com — we take those reports seriously, they are just handled through a different process and are not eligible for a bounty under this policy.

Findings against third-party services we integrate with are out of scope for a bounty, though we will pass along anything you responsibly report to the relevant vendor. Anything not explicitly listed above should be treated as out of scope. If you think a domain or property should be added, make the case to security@wallbox.com — we review these requests and will update the scope when it makes sense to. We reserve the right to change the target list at any time.

A few narrower scope notes worth calling out:

• Our billing system is out of scope as a target in its own right. That said, if a specific API endpoint is demonstrably called by one of the in-scope targets, that endpoint is in scope — endpoints that are never called from an in-scope instance are not.
• Internal and development services are out of scope. If you use one to pivot into an in-scope production system through lateral movement or privilege escalation, that chain is in scope — but bugs confined to a dev/staging environment are not, since those environments are expected to run less-hardened code.

What we expect from you while testing

We want researchers to be able to test in good faith without walking on eggshells, but a few rules keep testing safe for our customers and fair for everyone in the program:

• Never impact customer data or service availability. Don't run stress tests, denial of service attempts (application or network layer), or anything else that could degrade the platform for real users.
• Stop at proof, don't go further. If you find what looks like customer data, employee credentials, or API keys, report it immediately — do not attempt to confirm they work, log in with them, or pull additional records to "prove" the finding further.
• Don't chain beyond what you found. Using one vulnerability to go hunting for a second, unrelated one (pivoting or post-exploitation) is not permitted under this program.
• No social engineering, phishing, or physical testing. This program covers technical vulnerabilities in our software; it does not extend to our people, offices, or equipment.
• No automated scanners. Mass, unauthenticated scanning generates noise for our team and load on our infrastructure without the judgment a human researcher brings — reports generated this way are not eligible, and repeated use may result in removal from the program.
• Never make this a negotiation. Reporting a vulnerability must never come with conditions attached — leveraging a finding for payment demands or threats is extortion, not security research, and we will treat it as such.

Reports we don't reward

Some categories of report come in often enough, with little enough real-world risk, that we don't consider them for a bounty. This isn't a judgment on the effort behind them — it just means our security posture already accounts for them, or the underlying behavior isn't something we treat as a vulnerability:

• Missing security headers (e.g. Strict-Transport-Security, X-Frame-Options, Content-Security-Policy), missing SPF/DMARC records, or other configuration hardening suggestions without a demonstrated exploit.
• Clickjacking, and issues that are only exploitable through clickjacking.
• Self-XSS, or XSS that requires local access such as User-Agent header injection — unless paired with a working off-path MITM attack that lets it trigger for another user.
• CSRF on forms available to anonymous users, CSRF that requires knowledge of the token itself, or logout CSRF.
• Username/email enumeration, or disclosure of non-sensitive identifiers (issue keys, project keys, commit hashes).
• Descriptive error messages, stack traces, banner/version fingerprinting, or HTTP 404s and other non-200 responses.
• Rate limiting gaps on login/password-reset forms, weak CAPTCHAs, or lack of account lockout.
• SSL/TLS configuration findings (cipher suites, forward secrecy, BEAST/BREACH-class issues), or issues limited to browsers we no longer support.
• Reports that a dependency is outdated, without a demonstrated, working exploit against our use of it.
• Content spoofing, autocomplete/save-password prompts, or email bombing/flooding.

Anything not listed here is still worth reporting — when in doubt, send it to security@wallbox.com and let us make the call.

Rewards

We score reports using CVSSv3, and pay according to the severity that results. Where a researcher's own severity estimate differs from our CVSS scoring, we defer to CVSS to keep the program consistent across reports.

A few categories are deliberately scored one tier below what their raw CVSS score would suggest, because the practical risk they carry is lower than the score implies: open redirects, and access-control or privilege-escalation bugs that only let an existing Administrator perform System Administrator actions, are both paid at the P4 rate rather than P3. XSS affecting Wallbox servers is paid at the P3 rate rather than P2.

Findings that fall outside these categories entirely are still worth submitting. We'll acknowledge them as kudos-only reports, and any payout beyond that is at our discretion. Every reward decision is ultimately ours to make, but we aim to be consistent and fair about it — and we'll tell you how we arrived at a given severity if you ask.

Public disclosure

We support coordinated disclosure, and we want researchers to be able to take public credit for the work they put into finding real issues.

Once a reported issue is fixed and we've confirmed the fix is live everywhere it needs to be — not just on the instance you originally tested — you're welcome to publish a technical writeup and credit yourself as the researcher who found it. Before you do, please:

• Agree on timing with security@wallbox.com first, rather than setting your own disclosure deadline unilaterally.
• Share your draft with us ahead of publishing. We're not looking to water down your findings — we want to confirm the technical details are accurate and that the described impact matches what we actually fixed.
• Leave out any sensitive customer or company data you encountered while testing, even if you're confident it's no longer exploitable.

If we haven't agreed on a publication date within 90 days of the fix going live, you're free to proceed with disclosure after letting us know — we don't expect coordination to become an indefinite delay.

Safe harbor

When your research is conducted in line with this policy, we consider it:

• Authorized under the Computer Fraud and Abuse Act (CFAA) and equivalent state laws — we will not pursue or support legal action for accidental, good-faith violations of this policy;
• Exempt from the Digital Millennium Copyright Act (DMCA) with respect to any circumvention of technical controls involved;
• Exempt from any restriction in our Terms & Conditions that would otherwise interfere with this kind of research, which we waive on a limited basis for work done under this policy; and
• Lawful, conducted in good faith, and helpful to the security of the wider Internet.

You're still expected to comply with all applicable laws while you do this. If you're ever unsure whether something you're about to try is consistent with this policy, ask us first at security@wallbox.com — that email exists for exactly this kind of question, not just for finished reports.

Questions about this policy, or about whether a specific target is in scope, can go to security@wallbox.com. Thank you for helping keep Wallbox and its customers secure.