Skip to content

dotPulse 3.2.1 (security release)

Choose a tag to compare

@davmont davmont released this 09 Nov 16:33
· 5 commits to master since this release

Release date: 2026-11-09

dotPulse 3.2.1 is a security release. A review of how every page and handler reads its request found that logged-in users could raise their own permissions, take over another account, run SQL injection, and change or delete records they are not allowed to edit. Upgrade every installation of 3.2.0 or earlier. See advisory GHSA-rj5g-wp63-485q.

It upgrades 3.2.0 in place, with no database changes.


Security

Every issue below needed a logged-in account, except the last one, and most needed only ordinary user rights.

  • Privilege escalation (critical). The task save handler could be made to run the handlers of other modules, such as System Admin's permission and configuration handlers, under the tasks module's permission check. A user who could add tasks could give themselves any permission. The handler no longer runs other modules' files.
  • Account takeover. A user who could edit contacts could change the e-mail address of another user's account contact, the address a password reset is sent to. Only those who manage users may now change another user's account contact, and someone else's private contact can only be changed by its owner, as on the contact form.
  • SQL injection. Request values reached SQL unchecked in: the project lists (through a value the holiday module stored in the session, and through the department filter), task saving, task assignment, the task organiser's sort order, tasks per user, the department Gantt tabs of projects and macroprojects, macroproject finances and two macroproject reports, calendar invitations, forum watches and posts, invoice deletion, and the System Admin role pages (administrators only). Ids are now integers everywhere they reach SQL, and CDpObject::bind() keeps a record's id an integer, so a raw request value no longer stays on the object.
  • Records changed without permission on them. Many handlers checked the module permission but not the record. They now check the record and its project, as the pages that show the forms do:
    • tasks: saving into a project the user cannot see, assignments, task logs (also from timecard), bulk actions in the task organiser, the to-do list, the project designer and the interactive Gantt, adding tasks in bulk, importing tasks from a project;
    • messages: sending a message could overwrite any task;
    • files: moving files in bulk; replacing a file through a file custom field;
    • forums: reading messages of other forums through the reply form; editing or deleting others' messages;
    • helpdesk: items of companies the user may not see or edit (viewing, editing, logging time), and its time logs, which are shared with project tasks;
    • earnings: approving one's own earning, marking earnings paid, changing rates, billing other users' task logs, changing or deleting others' earnings; the notification e-mail went to an address taken from the request;
    • timesheets and timetrack: approving one's own timesheet, changing others' timesheets and entries;
    • macroprojects, risks, annotations, communication, journal, change requests (monitoring and control) and human resource allocations;
    • ticketsmith: read-only users could change tickets and send e-mail from the system;
    • files: checking out, or cancelling the checkout of, a file the user cannot edit; saving a file into a project, task or folder the user may not use; a file's owner could be changed;
    • projects: the creator could be set to another user, and the company to one the user may not see;
    • closure (post mortems), initiating (project charters), testing, payments (marking any invoice paid), hosting, mileage log, document management (mngdocument) and human resources (people, roles, company policies): the handlers now check the record, its project or company, and keep the creator;
    • activity logs (dotproject_plus): a log could be recorded for another user, and any project editor could delete any log; now only its author, the project owner or an administrator;
    • earnings: any user could open the managers' lists and other users' earnings.
  • Lists and pickers showing records the user may not see. The risk lists, the selection pop-ups (tasks, files, folders, forums, documents, helpdesk items, contacts, companies, departments), the company picker of the contact form, the meeting, change request and baseline pages of monitoring and control, the time planning estimations tab and the closure form now show only what the user may view. A user's own log in their account page could show another user's log.
  • Escaping: a value of the task-per-user reports and the macroproject finances export link was printed unescaped (only for the user who sent it, and blocked by the content security policy); the mileage log settings page (administrators only).
  • SQL injection by administrators in custom fields and the helpdesk settings: the values now reach SQL as parameters or integers.
  • Stored HTML injection in inventory brand and category names.
  • The installer showed an installed site's database host, name, prefix and user to anyone who opened it (not the password). It now leaves them empty: enter them, with the password, from includes/config.php when upgrading.

Fixes found on the way

  • The risk list ran three shell commands (column names written in backticks) every time it was shown.
  • Editing a forum message was a fatal error.
  • Deleting an invoice did nothing.
  • Removing a human resource from a task deleted an unrelated allocation (the one whose id was the task's).
  • In the task organiser, marking a task's subtasks finished checked the wrong task.
  • The to-do list deleted tasks without what goes with them (subtasks, assignments, logs).
  • Saving a hosting entry deleted the domain and created a new one (losing its custom fields), and the hosting expiry date was not saved.
  • Mileage logs could not be saved (a leftover debug stop).
  • Human resource roles were not saved with the person.
  • The helpdesk's selection pop-ups for companies, departments and projects, and the generic one for helpdesk items, failed with an SQL error.
  • Initiating: the dates of a project charter were not converted before saving.
  • Macroproject task-per-user report: two options were lost when the form was sent.

Upgrading

  1. Back up the database and the files/ directory.
  2. Replace the code. Keep includes/config.php and files/.
  3. Run the installer (install/ in a browser) to record the new version. There are no database changes. Then remove install/ again or deny access to it.

From a version older than 3.2.0, read the 3.2.0 release notes first.

Requirements

  • PHP 8.2 or later (8.3 is tested), MySQL or MariaDB.
  • Apache (recommended) or nginx with the rules from the deployment guide.