Incident report final touch.

opensaas-sh/blog/src/content/docs/blog/2025-02-26-incident-report-vulnerability-in-open-saas.mdx

@@ -1,8 +1,8 @@
 ---
-title: "Security Vulnerability in Open SaaS Template"
+title: "Incident Report: Security Vulnerability in Open SaaS \"updateCurrentUser\" function"
 date: 2025-02-26
 tags:
-  - security
+  - incident-report
 authors: martin
 ---
 import { Image } from 'astro:assets';
@@ -11,7 +11,7 @@ On Feb 12th, 2025, we learned about a security vulnerability in the `updateCurre
 
 **If you created your app with the Open SaaS template before Feb 14th of '25, your app potentially suffers from this vulnerability, and you should apply the fix from this report as soon as possible**. Check out [vulnerability](#the-vulnerability) and [fix](#the-fix) sections.
 
-The vulnerability does not affect the apps built with the Wasp framework or those that modified the problematic part of the code enough to eliminate the problem.
+The vulnerability does not affect the "vanilla" Wasp apps (Wasp apps not built with Open SaaS template) or those that modified the problematic part of the code enough to eliminate the problem.
 
 Since then we fixed the vulnerability in all the versions of the Open SaaS template, did a [coordinated vulnerability disclosure](https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure) (culminating with this report) with the suggested fix, reviewed all the other templates and example apps of ours for similar security vulnerabilities, analyzed what at the first place enabled such omission to happen on our side, and prepared a plan on how to minimize the chance of similar mistakes happening in the future. 
 
@@ -140,7 +140,7 @@ Notice that we modified the shape of the operation input (now it is `{ id, isAdm
 
 ## Additional reading
 
-The second part of the report is not required reading: all you need to know in order to fix the vulnerability is in the "[The vulnerability](#the-vulnerability)" and the "[The fix](#the-fix)" sections. But, if you want to learn more about what caused the vulnerability, how we handled it, and what are we doing to prevent similar mistakes from happening in the future, read on!
+This second part of the report is not required reading: all you need to know in order to fix the vulnerability is in the "[The vulnerability](#the-vulnerability)" and the "[The fix](#the-fix)" sections. But, if you want to learn more about what caused the vulnerability, how we handled it, and what are we doing to prevent similar mistakes from happening in the future, read on!
 
 
 ## Coordinated vulnerability disclosure
@@ -151,7 +151,7 @@ One of the popular approaches is [coordinated vulnerability disclosure](https://
 
 1. Stage 1 (private disclosure): We assembled a list of everybody we knew was building and deploying apps with Wasp / Open SaaS, be it from our community on Discord, from online search, or from interacting with them in the past. We privately reached out to everybody on the list and shared the details of the vulnerability and the fix, while also asking them to keep it confidential till we go public with it.
 2. Stage 2 (community disclosure): About a week later, we shared the details of the vulnerability in our Discord community, while again asking people not to share it publicly till we go public with it.
-3. Stage 3 (public disclosure): Finally, a bit less than a week after Stage 2, we shared the vulnerability fully publicly.
+3. Stage 3 (public disclosure): Finally, a week after the Stage 2, we shared the vulnerability fully publicly.
 
 ## How did this happen?
 
@@ -167,7 +167,7 @@ Open SaaS started as a one-person experiment, a simple template/boilerplate star
 
 Open SaaS did shape up, and not only have people started using it, but it really picked up, more than we ever expected, and we were getting a lot of positive and constructive feedback, feature requests, ideas, bug reports, … . We started reviewing all the new code thoroughly, but we still haven't done the full retroactive review. We have done some of it, for parts of more sensitive modules, and some of it happened naturally through refactoring, but we haven't done it systematically for the whole codebase. We would discuss during every quarterly planning how we should do it this quarter, but there was always something with a higher priority, especially on the Wasp side, and Open SaaS was doing great, if there was anything serious, we would already know about it, we thought.
 
-And then we did learn about it. A function that allows a user to set any data, without runtime validation, as a partial update for their `User` record in the database. This function was barely even used in the Open SaaS codebase at this point: it was used only to update a single field in the `User` database model, and even that usage should have been refactored into something better already. This function was an obvious code smell, but we never reviewed it properly.
+And then we learned about a function in our codebase that allows a user to set any data, without runtime validation, as a partial update for their `User` record in the database. This function was barely even used in the Open SaaS codebase at this point: it was used only to update a single field in the `User` database model, and even that usage should have been refactored into something better already. This function was an obvious code smell, but we never reviewed it properly.
 
 The fact is, we never should have made Open SaaS publicly available without doing a full code review of it first. Once the code is out there, be it just an example app, a template, or a library, we can't guess how it or its usage will evolve, or how will our priorities evolve. Once an exception in the (review) process is made, it is much harder to find the time to catch up on it, than if we did it when we should have done it in the first place.
 
@@ -196,15 +196,15 @@ What follows is the timeline of the actions we have taken since we learned about
     - Started a deep (re)review of all the Open SaaS code (that will continue into the next week).
 - Feb 17th (Mon):
     - Continued deep review of Open SaaS code.
-- Feb 18th (Tue): TODO (update timeline from here further)
+- Feb 18th (Tue):
     - Continued deep review of Open SaaS code.
     - Finalized first draft of this Incident Report document.
 - Feb 19th (Wed):
     - Continued deep review of Open SaaS code.
 - Feb 20th (Thu):
     - Continued deep review of Open SaaS code.
-    - Notified our Discord community about the incident by sharing the "Incident Notification" document with them, giving them a bit less than a week of head start before we go fully public with the incident.
+    - Notified our Discord community about the incident by sharing the "Incident Notification" document with them, giving them a week of head start before we go fully public with the incident.
 - Feb 21st (Fri):
-    - Finalized the deep review of the Open SaaS code.
+    - Finalized the deep review of the Open SaaS code (while continuing with the code improvements).
 - Feb 26th (Wed):
     - Went public with the incident by publishing and sharing this Incident Report.