Direct-upload replay is the Important line in OpenProject 17.8.1

So OpenProject put 17.8.1 on the feed, dated September 30, 2026. We flagged it Important as a security fix. Recency wants the calm opener: several bug fixes, update to the newest version, here is a short list. Fine. Those are the lines people screenshot when they skim a project-management patch tag.

The line that matters, to the best of my understanding, is GHSA-c5j2-2mfg-49h7. Direct uploads to S3-compatible attachment storage could be replayed after the upload finished. A user allowed to add attachments could reuse the signed upload form for their own attachment and replace the file after antivirus had already cleared it. Other users then downloaded the replaced, unscanned content while OpenProject still showed the attachment as scanned. Only installs with remote (S3-compatible) storage and direct uploads are in scope. Direct uploads are on by default whenever S3 is configured. Local filesystem storage is not affected. Impact is highest where antivirus scanning is on, because the scan result no longer matches what gets served. Affected versions start at 16.5.0.

The patch in 17.8.1 (and 17.9.0) changes the flow. Uploads land in a staging location first. OpenProject copies to the final object itself once the upload completes. The form can no longer write over a completed attachment. Forms also expire sooner (4 hours instead of 10). You can tune that with OPENPROJECT_FOG__DIRECT__UPLOAD__EXPIRES__IN (seconds) for big uploads on slow links. Abandoned staged objects can linger in the bucket, so they recommend a lifecycle rule. Forms issued before the upgrade stay valid until they expire. Rotate the S3 access key after upgrading if you need those old forms dead immediately. Workaround without patching: OPENPROJECT_DIRECT__UPLOADS=false so uploads go through the OpenProject server instead of straight to S3.

There are two sibling security rows in the same note. GHSA-4p83-c4wg-59q4: meeting agenda item API could leak private work package subjects through a shared representer cache to users who should not see those subjects. GHSA-r374-cr8p-hmp9: changing a password did not invalidate other active sessions, so a stolen session could keep working after password rotation. Kind of easy to paste all three GHSA ids into a status update and sound thorough. Kind of useless when the partner ticket is "our AV-cleared attachment was not the file we downloaded" on an S3-backed OpenProject.

I keep almost filing OpenProject under "project tool patch, ignore." Kind of the wrong habit when you sell into teams that host OpenProject on S3 attachments with antivirus in the path, or anyone who treats meeting agendas as a privacy boundary. Tracking product change here means reading past the bug-fix list and asking which line changes a partner ticket. Let's say the talking point is not "17.8.1 shipped security fixes." It is reusable direct-upload forms can rewrite a cleared attachment (and the patch stages uploads, shortens form lifetime, and may need an S3 key rotate), then yes mention the meeting subject leak and sessions that survive password change. We pull it into a uniform entry shape at /sources/openproject.releases. Same JSON as everything else. Recency still wants the bug-fix opener. Recency is not the direct-upload replay.