ERPNext Security Hardening Checklist (CVEs, Backups, SOC 2 Vendor Questions)

At a glance

Frappe Framework has had real CVEs, but every one was patched fast in a released version, so the control that matters is upgrade discipline. This guide lists the recent CVEs with their fixed versions, provides a hardening checklist covering identity, network, data, updates, backups, and monitoring, and shows how to answer SOC 2 vendor questionnaires. It closes with the self-hosted vs managed security decision.

Is ERPNext Secure?

ERPNext is as secure as its operation. Frappe Framework has had real CVEs — including SQL injection and a remote-code-execution path — all patched in released versions, typically within days of disclosure. Instances that track stable releases and restrict server access have a strong record; unpatched self-hosted instances are where incidents happen. Upgrade discipline is the control that matters.

That's not a dodge — it's how security actually works for any self-hosted business system. The question "is ERPNext secure?" decomposes into two questions with different answers: Does the project handle vulnerabilities well? (Yes — public disclosure, fast patches, an advisory process.) Will your instance be secure? (That depends entirely on whether you patch, how you expose it, and who can reach the server.) Let's take both seriously.

Recent Frappe/ERPNext CVEs — and What They Actually Mean

Here are the recent CVEs the fear headlines reference, with the detail they usually omit — the fixed versions:

CVE-2025-30212 is an SQL injection (an authenticated user could access data beyond their permissions), fixed in 14.89.0 / 15.51.0 — see NVD.

CVE-2025-30213 is improper input validation leading to possible remote code execution, fixed in 14.91.0 / 15.52.0 — see NVD.

CVE-2025-30217 is an SQL injection leading to sensitive information access, fixed in 14.93.2 / 15.55.0 — see NVD and the GitHub advisory.

CVE-2026-35614 is an SQL injection in bulk_update, fixed in 16.14.0 / 15.104.0 — see CVE.org.

Read the "Fixed in" column twice, because it's the whole story: every one of these is fixed in a released version. If your instance is current on the stable branch, none of them applies to you. If your instance is a v14 install someone set up in 2023 and never touched, sitting on a public IP — that's where these CVEs stop being history and start being your attack surface. (If you cite severity internally, pull the CVSS score from the NVD page for each CVE rather than from headlines; we deliberately don't paraphrase severity here.)

The pattern worth understanding: public CVEs are the healthy sign

Open source means public disclosure. You can see every Frappe vulnerability, its fix, and its timeline — that's uncomfortable in a Google search and invaluable in a risk assessment. Proprietary ERPs have vulnerabilities too; you simply never hear about most of them, because nothing obligates disclosure. A project with public CVEs and fast patches has a working security process. A product with zero published CVEs has either perfect code or an opaque process — and perfect code doesn't exist.

What the headlines don't say

Exposure requires two ingredients the headlines gloss over: an old version, and reachability. Most of these issues also required an authenticated user or a specific exposed endpoint. The practical risk formula is: unpatched version + open internet + weak access controls. Remove any one ingredient and the picture changes dramatically. Remove all three — which is what the checklist below does — and you're running a tighter ship than most SMB SaaS stacks.

Where to watch

Subscribe to two sources and you'll never learn about a Frappe vulnerability from a headline again: the GitHub security advisories for frappe/frappe, and Frappe's security page, which also documents how to report issues responsibly.

Not sure which version you're running — or whether these CVEs apply to you? Get a free ERP audit and we'll tell you in one call.

The ERPNext Hardening Checklist

Run through this top to bottom. Most items are an hour or less; together they close the gaps that actually get exploited.

Identity & access

• Audit role permissions for least privilege. ERPNext's role system is granular — use it. Nobody needs System Manager to approve purchase orders. Review quarterly.
• Disable unused default roles and demo users. Fresh installs carry more enabled surface than most companies need.
• Lock down Administrator. Strong unique password, used only for administration, never for daily work. Day-to-day users get named accounts — that's also your audit trail.
• Enable two-factor authentication. bench --site yoursite set-config enable_two_factor_auth true, then configure method (OTP app recommended) in System Settings; 2FA can also be applied per-role (docs). This is the single highest-value hour on this list.
• Set session expiry in System Settings so abandoned sessions die on their own.

Network

• HTTPS only. Bench's Let's Encrypt integration makes TLS a ten-minute job; there is no excuse for an ERP on plain HTTP.
• Bind MariaDB and Redis to localhost and firewall everything except 80/443. A database port on a public IP is how SQL-injection CVEs become data breaches.
• SSH: keys only, no password auth, plus fail2ban. Brute-force bots find every public SSH port within hours.
• Consider a VPN or IP allowlist for administrative paths if your team's access patterns allow it — it removes the open-internet ingredient from the risk formula entirely.

Data

• Encryption at rest: disk-level (LUKS) or your cloud provider's managed-volume encryption; MariaDB's own at-rest encryption is available if policy requires it.
• Encrypt backups and store them off-site — a backup containing your entire GL deserves the same protection as the database.
• Treat site_config.json as a secret. It holds database credentials and the site encryption key; restrict file permissions and keep it out of any repository.

Update cadence — the control that matters most

• Pin to the stable branch and apply minor updates at least monthly via bench update.
• Subscribe to the GitHub advisories (above) and treat a security release as a this-week task, not a this-quarter one.
• Staging first, then production. A staging bench costs a few dollars a month and converts upgrade anxiety into routine.

Backup and disaster recovery

• bench backup --with-files on an automated schedule (reference) — the --with-files flag matters; attachments are business data too.
• Copy backups off-server (S3, Backblaze B2, anywhere that isn't the same machine). The community has documented solid low-cost patterns for exactly this (example).
• Test restores periodically. A backup you've never restored is a hope, not a backup. Restore to a scratch server quarterly and write down how long it took — that's your real RTO, and the number your SOC 2 questionnaire will ask for.
• Document RTO/RPO targets, even informally. "Nightly backups, 4-hour restore" is an answer; a shrug is not.

Monitoring

• Review failed-login activity, watch the error logs, and set uptime and disk-space alerts. None of this is ERPNext-specific — it's the basic operational hygiene that turns incidents into non-events.

How Do You Answer a SOC 2 Vendor Questionnaire with ERPNext?

You're answering about your controls, not ERPNext's. Map each questionnaire item to your actual practice: access control → ERPNext role permissions and 2FA; change management → staged updates; backup → documented schedule and restore tests; encryption → TLS plus disk encryption. If self-hosting makes those answers thin, managed hosting — Frappe Cloud or a partner — lets you inherit stronger answers.

This question is landing on more $2–20M companies every year: your enterprise customer's procurement team sends a 40-row spreadsheet asking about your systems, and your ERP is on it. The good news is that the questionnaire asks about your controls, and if you ran the checklist above, you already have the answers. A sample mapping:

Access control & reviews → Role-based permissions, least privilege, quarterly access reviews, 2FA enforced.

Encryption in transit / at rest → TLS on all connections; disk-level encryption on server and backups.

Change management → Stable-branch releases, staging environment, documented update cadence.

Backup & recovery → Nightly bench backup --with-files, off-site copies, quarterly restore tests, stated RTO/RPO.

Vulnerability management → Subscribed to Frappe GitHub advisories; security patches applied within days.

Incident response → Named owner, monitoring/alerting in place, escalation path documented.

On hosted options: Frappe Cloud publishes compliance documentation, including a SOC 2 report page in its docs, and has historically referenced ISO 27001 certification. Certifications have scopes and renewal dates, so do what your customer's auditor would do: request current certificates directly from Frappe at evaluation time rather than relying on any blog post — including this one. Frappe Cloud also supports 2FA at the platform level.

The honest note: using ERPNext — or NetSuite, or anything else — does not make you SOC 2 compliant. SOC 2 attests to your organization's controls. An ERP with good primitives makes the evidence easier to produce; it cannot produce the discipline for you.

Self-Hosted vs Managed: The Real Security Decision

Strip away the architecture debate and the security decision is three questions: who patches, who monitors, and who answers the phone when something breaks at 2 a.m.?

We implement on all three, and our position hasn't changed since our self-hosted vs Frappe Cloud breakdown: self-hosting is legitimate with ops capacity behind it. What most $2–20M companies without a dedicated sysadmin should not do is run an unmanaged, unpatched instance on a public IP — that's the configuration every CVE in the table above is waiting for. For the sizing and cost math behind this decision, see the companion post on self-hosting requirements and real costs; for where security fits in the broader honest-limits picture, our running list is here.

• Self-hosted, unmanaged: you do all three. Entirely viable with a competent sysadmin and the checklist above — and the configuration behind most real-world incidents when nobody owns it.
• Frappe Cloud: Frappe patches the platform and manages backups; you still own user access, roles, and your own data hygiene.
• Partner-managed: a partner (like us) owns patching, monitoring, backups, and incident response under an agreement, on infrastructure sized to your needs.

Bottom line

ERPNext's security story is unremarkable in the best way: real vulnerabilities, found and fixed fast, with public accountability — and an operational burden that lands on whoever runs the instance. If that's you, run the checklist. If you'd rather it weren't you, that's exactly what managed hosting and implementation are for: we patch, monitor, and back up — so your SOC 2 answers are easy and your version is never the one in the headline. Transparent pricing, implementations from $4,000. Want the one-page ERPNext Security Hardening Checklist plus a sample SOC 2 vendor-questionnaire answer sheet? Ask us →