🤖 Securing Redmine: Vulnerabilities, Attack Vectors, Hardening, and Patch Monitoring

Redmine is an open-source, Ruby on Rails–based project management and issue-tracking platform. Because it exposes a rich web interface, REST APIs, e-mail integration, source-control browsing, and pluggable extensions, it has accumulated a substantial — but actively managed — vulnerability history. This report synthesizes Redmine’s official security advisories, NVD/CVE records, Ruby on Rails security disclosures, and reputable third-party research to give administrators a practical view of (1) the categories of weaknesses that have appeared in Redmine, (2) the attack vectors that follow from those patterns, (3) the architectural and configuration hardening that reduces the impact of unknown (zero-day) bugs, and (4) the channels to monitor so that patches are applied quickly.

1. Historical Vulnerability Categories and Concrete CVE Examples

Reviewing the official Redmine “Security Advisories” wiki page (which lists every vulnerability fixed since 1.3.0) together with the NVD/CVE database shows that Redmine’s bug history is dominated by a handful of recurring weakness classes. The following groupings reflect what has actually been disclosed and patched.

1.1 Cross-Site Scripting (XSS) — The Single Largest Class

XSS is by far the most frequent issue type. Redmine renders user-controlled content in many places (Textile, Markdown, wiki pages, issue subjects, custom fields, macros, mentions, thumbnails, flash messages, the back_url parameter), and small sanitization regressions repeatedly produce stored or DOM-based XSS. Representative cases:

1.2 SQL Injection

Direct SQLi in Redmine itself is rare but has occurred. The most notable case is CVE-2019-18890, a critical SQL injection (CWE-89) in versions ≤ 3.3.9 that allowed an authenticated user to access protected information via a crafted object query. It was patched in 3.3.10. Older mass-assignment issues (e.g., the 2012 fix in 1.3.2) also bordered on this class.

1.3 Remote Code Execution / Command Injection (Especially via SCM Adapters)

Redmine shells out to external SCM binaries (git, hg, bzr, svn), which has historically been the most dangerous attack surface:

  • CVE-2011-4929 — Arbitrary command execution in the SCM repository controller via an unfiltered rev parameter; an unauthenticated Metasploit module (exploit/unix/webapp/redmine_scm_exec) still exists for legacy installs.
  • CVE-2017-18026 / CVE-2017-17536 — Remote command execution through the Mercurial adapter by abusing branch names that begin with --config= or --debugger= flags to hg.
  • CVE-2022-24724 — RCE in the bundled commonmarker gem (cmark-gfm); affected Redmine 5.0.0/5.0.1.
  • CVE-2016-3714 (“ImageTragick”) — Critical RCE through ImageMagick processing of attachments (affects all Redmine ≥ 2.1.0 until patches).

1.4 Authentication, Authorization, and Permission Bypass

A consistent pattern: features added later (REST API, mail handler, attachments, watchers, time entries, 2FA) sometimes fail to re-check the same authorization that the web UI enforces.

  • CVE-2022-44030 — Critical access control issue in attachments#download_all allowing download of attachments on issues the user could not see (Redmine 5.0.0–5.0.3).
  • CVE-2024-47225 — Insufficient permission check: the “Add watchers” permission effectively granted “View watchers” as well.
  • Defect #43634/#43635 (2025) — Authorization bypass enabling modification or deletion of attachment metadata on invisible issues.
  • Defect #43830 (2026) — A user limited to viewing only their own time entries could retrieve other users’ entries via the REST API.
  • CVE-2021-30164 — Issues API bypassed the add_issue_notes permission.
  • CVE-2021-31864 — Same bypass via the incoming mail handler.
  • CVE-2021-37156 — User sessions were not reset after enabling 2FA (4.2.0/4.2.1).
  • Defect #43083 (2025) — Information disclosure in the 2FA mechanism itself.
  • Defect #42194 (2025) — /my/account did not correctly enforce sudo mode.

1.5 Information Disclosure / Insufficient Access Filtering

Many fixes address subtle leaks rather than full takeover:

  • CVE-2021-42326 — Activities index view leaked usernames.
  • CVE-2021-30163 — Names of private projects leaked via issue-journal project_id changes.
  • CVE-2020-36308 — Time-entries CSV export disclosed subjects of issues the user could not see.
  • CVE-2017-16804 — E-mail reminders revealed information about inaccessible issues.
  • CVE-2017-15572 — lost_password flow leaked password-reset tokens via HTTP Referer.
  • CVE-2017-15573 / CVE-2017-15576 / CVE-2017-15577 — Information leaks in wiki link rendering, time-entry rendering, and atom feeds (CVE-2015-8537).
  • Defect #42352 (2025) — ProjectQuery leaked details of private projects.
  • Defect #43161 (2025) — Issue-copy reused custom values without proper validation, leaking data.

1.6 Path Traversal, Arbitrary File Read, and File-Upload Issues

  • CVE-2021-31863 — Critical arbitrary file read in the Git adapter.
  • Defect #43690 (2026) — Directory traversal via backslash-separated paths in the filesystem SCM adapter.
  • Defect #43451 (2025) — Critical: PostScript files disguised as PDF triggered arbitrary file operations during thumbnail generation (affects all releases since 4.2.0).
  • CVE-2021-31865 — Allowed file extensions for attachments could be circumvented.
  • CVE-2017-15574 — Stored XSS via SVG attachments (file-type/content-handling issue).

1.7 LDAP Injection

  • Defect #43692 (2026) — LDAP injection from unescaped input in the LDAP search filter (fixed in 6.1.2 / 6.0.9 / 5.1.12).

1.8 CSRF and Open Redirect

  • A CSRF protection bypass was fixed in Redmine 1.3.0 (pre-CVE era).
  • An early CSRF allowing ticket deletion existed in Redmine ≤ 0.8.5.
  • CVE-2014-1985, CVE-2015-8474, and the later #37880 open-redirect in attachments#download_all are the main open-redirect cases — typically via the back_url parameter.

1.9 Timing, Cryptographic, and Session Issues

  • CVE-2021-31866 — SysController and MailHandlerController were vulnerable to timing attacks against API keys (string-comparison side channels).
  • Defect #42998 (2025) — Username and password were inadvertently stored in the login form HTML.

1.10 Vulnerabilities Inherited from the Ruby/Rails Stack and Bundled Gems

A very large fraction of Redmine’s advisories simply pin newer versions of Rails and gems whose flaws affect the application. Examples include:

1.11 Mass Assignment

Redmine 1.3.2 fixed a mass-assignment vulnerability allowing attackers to set protected attributes on Comment, Document, IssueCategory, Members, Message, News, and TimeEntry models — a class of issue Rails itself addressed soon after via strong_parameters.

2. Attack Vectors Administrators Should Expect

The historical pattern lets us predict where attackers (and pen-testers) focus. Hadess’ Redmine attack-surface analysis and the cumulative advisories converge on the same hot spots.

2.1 Text Formatters and Wiki/Issue Content

The Textile and Markdown rendering pipelines are the single most repeatedly broken component. Any field where users can author rich text — issue descriptions, notes, wiki pages, custom fields, project descriptions — should be considered a perpetual XSS target. The same applies to embedded thumbnails and SVG attachments.

2.2 The REST API and Atom Feeds

Multiple bypasses (CVE-2021-30164, #43830, CVE-2015-8537/8473) show that API endpoints sometimes apply weaker authorization than the equivalent web UI. APIs and feeds should be treated as a separate authorization domain that needs its own review.

2.3 Inbound E-mail (MailHandler)

The mail handler has produced bypasses (CVE-2021-31864), timing attacks (CVE-2021-31866), and is the kind of unauthenticated entry point that deserves heightened monitoring. If you do not need e-mail-to-issue, disable it.

2.4 Repository Browser / SCM Adapters

The biggest critical-severity Redmine bugs (CVE-2017-18026, CVE-2021-31863, #43690) all live here. Any feature that shells out to git, hg, svn, or bzr with semi-controlled arguments (branch names, paths, revisions) is high risk.

2.5 File Uploads, Attachments, and Thumbnails

Allowed-extension bypasses (CVE-2021-31865), permission gaps on download_all (CVE-2022-44030, #43634/#43635), the PostScript-as-PDF thumbnail RCE (#43451), and SVG-based stored XSS (CVE-2017-15574) make this an enduring hot spot. ImageMagick / libvips invocations during thumbnailing add a kernel of native-code risk.

2.6 Authentication / Session Layer

Look for: brute-force login (Redmine has no native rate limiting on the login form — the redmine_stronger plugin is a popular community remedy), 2FA edge cases, password-reset token leaks via Referer, and timing leaks on API keys.

2.7 Redirect / back_url Parameter

Open redirects and reflected XSS have repeatedly hidden in the back_url query parameter (CVE-2015-8474, CVE-2020-36306, CVE-2014-1985).

2.8 LDAP/AD Authentication Path

LDAP injection (#43692) and the long-standing recommendation never to bind Redmine to an LDAP service account that is also a domain admin make AD integration a notable vector.

2.9 Plugins and Themes

Redmine’s plugin ecosystem is large, lightly curated, and has direct database, filesystem, and view-rendering access. Many plugins lag the core in keeping up with Rails security releases, and a plugin can re-introduce classes of bug (XSS, SQLi, mass assignment) that the core has fixed. Plugins are widely considered the largest uncovered part of the Redmine attack surface.

2.10 CSV Exports (Spreadsheet “Formula Injection”)

Hadess and several internal advisories note the risk of CSV-injection payloads (=cmd|...!A1) embedded in issue fields and exfiltrated via export to users who open them in Excel/LibreOffice. Redmine does not strip these by default.

3. Reducing the Risk from Unknown / Zero-Day Vulnerabilities

Because most Redmine bugs cluster in predictable areas, defense-in-depth aimed at those areas is highly effective even against bugs that have not yet been disclosed.

3.1 Keep the Stack Patched on a Compressed Cycle

The single most effective control: track Redmine, Rails, Ruby, Bundler, and bundled gems on at least a monthly cycle, and within 24–72 hours when a security release is announced. Run bundle audit (from bundler-audit) and Brakeman in CI/CD against the deployed Gemfile.lock; both will catch the gem-level CVEs that account for much of Redmine’s advisory volume. Do not run end-of-life Redmine series — at the time of writing, only the 5.1, 6.0, and 6.1 series receive security fixes.

3.2 Architectural Isolation

  • Run as an unprivileged OS user in a dedicated UID, ideally inside a container or systemd-confined service with ProtectSystem=strict, NoNewPrivileges=yes, and a read-only root filesystem.
  • Place a reverse proxy in front (nginx or Apache + ModSecurity). ModSecurity with the OWASP CRS catches generic XSS, SQLi, path-traversal, and LFI patterns and has historically blocked exploitation of multiple Redmine CVEs before patches were deployed.
  • Network-segment the Redmine host. Outbound egress should be filtered: there is rarely a reason for the Redmine process to make arbitrary outbound HTTP, and restricting egress neutralizes most SSRF and “callback” exploitation chains.
  • Isolate the database. Use a dedicated DB user with privileges only on the Redmine schema; deny FILE, SUPER, and LOAD DATA LOCAL INFILE (MySQL) or superuser (PostgreSQL).
  • Isolate the SCM checkouts. Repositories Redmine reads should be read-only mounts, ideally on a separate volume; forbid the Redmine OS account from writing into them.
  • Front the application with a WAF (cloud or on-prem). Even a simple WAF rule blocking suspicious back_url, --config= / --debugger=, or .. payloads addresses several historical Redmine CVEs.

3.3 Configuration Hardening Inside Redmine

  • Force HTTPS end-to-end. Set Redmine’s Setting.protocol to https, enable HSTS at the proxy, and set autologin_cookie_secure: true in configuration.yml along with Secure and HttpOnly session cookies.
  • Disable self-registration and require approval. Many information-leak CVEs have a footnote noting “depending on configuration, this may require login as a registered user” — denying anonymous accounts neutralizes them.
  • Require authentication (login_required = yes) so that anonymous users cannot reach feeds, repository views, or the API at all.
  • Disable unused modules per project and globally: in particular disable SCM types you do not use in Administration → Settings → Repositories → Enabled SCM, and disable inbound mail handling if not needed.
  • Restrict allowed attachment extensions and block SVG/HTML/JS/executable types entirely. Run uploaded files through ClamAV on ingest.
  • Configure a Content Security Policy at the reverse proxy (default-src 'self'; object-src 'none'; frame-ancestors 'none'). A strict CSP turns most stored-XSS bugs into harmless cosmetic issues.
  • Add X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy at the proxy.
  • Two-factor authentication is built into modern Redmine and should be required for all administrators (and ideally everyone).
  • Rotate the API key of the system account used by MailHandler/Sys controllers, and restrict access to those endpoints by source IP.
  • Use the redmine_stronger plugin or upstream Rack::Attack to throttle login attempts and mitigate the lack of native brute-force protection.
  • For LDAP/AD, use a dedicated low-privilege bind account, never a domain admin, and verify the patch level for #43692 (LDAP injection).
  • Keep secret_key_base out of source control and rotate it on suspected compromise; this invalidates all signed cookies.

3.4 Plugin Discipline

  • Install only plugins you actively need; treat each plugin as code joining your trust boundary.
  • Pin plugin versions, monitor their issue trackers, and remove abandoned plugins.
  • Audit plugins with Brakeman, which understands Rails-specific issue classes (mass assignment, unsafe eval, command injection, unsafe redirect_to).

3.5 Operational Telemetry and Backups

  • Centralize Rails, web-server, and database logs with anomaly alerts on auth failures, 500 errors from the SCM controller, and unusual attachments#download_all activity.
  • Take regular encrypted, off-host backups of files/, the database, and config/. Test restoration.
  • Run Planio’s free Redmine Security Scanner periodically against the public endpoint; it black-box-detects out-of-date versions and missing security headers.

3.6 Defense in Depth for the Big Risk Hotspots

  • Repository browser: wrap external SCM commands behind an OS-level allow-list (AppArmor/SELinux), and ensure the binaries themselves are current. Disable the SCMs you do not use.
  • Thumbnail/Imaging pipeline: keep ImageMagick and libvips patched, configure ImageMagick’s policy.xml to deny coders you do not need (PS, EPS, PDF, MVG, MSL, URL, HTTPS), which kills both ImageTragick-style and the 2025 PostScript-thumbnail issues regardless of Redmine’s own validation.
  • Markup pipeline: prefer Markdown (CommonMarker) over Textile where possible; Redcloth-3-based Textile has the longer XSS history.

4. Where to Monitor for New Redmine Vulnerabilities and Patches

A Redmine administrator should subscribe to all of the following, because most fixes are announced first on Redmine’s own channels and only later surface in the CVE feeds.

4.1 Official Redmine Channels

  • Security Advisories wiki — the canonical, chronological list of every fixed issue, with severity, fixed-version, and external CVE/JVN references. Updated in lockstep with releases.
  • Redmine News feed — (and its RSS feed). Maintenance and security releases are announced here and usually summarize each fix by defect number.
  • The security@redmine.org reporting address is for reporting issues; there is no public mailing list of pending advisories from this address, so the wiki + news feed is the watch point.

4.2 Ruby and Rails Upstream Channels

  • Ruby on Rails: Security Discourse (the “Security Announcements” category) — current location after the legacy rubyonrails-security Google Group was retired.
  • The ruby-security-ann Google Group / mailing list — security announcements for Ruby itself, RubyGems, Bundler, and core gems.
  • ruby-lang.org/en/security/ — the Ruby language security newsfeed.
  • GitHub Advisory Database — filter by ecosystem rubygems. GitHub’s Dependabot will alert directly on a Redmine fork or any repo containing your Gemfile.lock.
  • bundler-audit reads the rubysec/ruby-advisory-db and is the single most useful CLI tool to add to CI.

4.3 CVE / Vulnerability Databases

4.4 OS Distributor Security Trackers

4.5 Hosted/Commercial Sources Worth Watching

  • Planio Blog and Redmine Security Scanner — Planio employs several core Redmine maintainers and frequently publishes practical guidance.
  • Easy Redmine and RedmineUP publish hardening checklists relevant to packaged distributions.
  • Tenable, Qualys, and Greenbone (OpenVAS) publish detection plugins for Redmine CVEs that are useful for vulnerability-management programs.

4.6 Recommended Monitoring Workflow

  1. Subscribe by RSS to redmine.org/news and the GitHub Security Advisories feed for the Redmine repository.
  2. Subscribe to the Rails Security Discourse and ruby-security-ann.
  3. Add bundler-audit and Brakeman to your CI; fail the build on new HIGH/CRITICAL findings.
  4. Run Planio’s Redmine Security Scanner against the public hostname on a weekly schedule.
  5. Maintain a documented patch SLA — CRITICAL within 24 hours, HIGH within 72 hours, MODERATE within 7 days, LOW within a month — and tie it back to the severity column in the official advisories wiki.

Summary

Redmine’s vulnerability history is dominated by XSS in its rich-text formatters and authorization gaps in API/email/attachment paths, with periodic critical issues in SCM adapters, image processing, and bundled gems. The single most important defensive action is timely patching of Redmine plus the entire Ruby/Rails/gem stack, monitored via the official Redmine Security Advisories page, the Rails Security Discourse, NVD, and bundler-audit. Beyond patching, defense-in-depth — TLS-everywhere, a WAF/ModSecurity, strict CSP and security headers, disabled self-registration, restricted attachment types, sandboxed SCM execution, an isolated DB user, hardened ImageMagick policies, mandatory 2FA for admins, and the disciplined use of plugins — neutralizes the majority of the bug classes Redmine has historically suffered, including ones not yet discovered.

Leave a Reply

Your email address will not be published. Required fields are marked *