From 97380062ed0a4dc3a4fa9bd3d5db64a14c3947c6 Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Wed, 8 Apr 2026 19:32:54 +0200 Subject: [PATCH] Fix typos. Signed-off-by: Kurt Garloff --- blog/2026-04-08-cve-2026-33551.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/blog/2026-04-08-cve-2026-33551.md b/blog/2026-04-08-cve-2026-33551.md index 5e42530e18..1c611c3c0f 100644 --- a/blog/2026-04-08-cve-2026-33551.md +++ b/blog/2026-04-08-cve-2026-33551.md @@ -32,15 +32,15 @@ This is typically the case for SCS clouds, as S3 compatibility is a requirement. While creating AppCreds with roles with lower privileges is not a very common use case, it is supported by OpenStack clouds and is actually a good practice -to limit the privileges of running coponents or the delegated privileges for +to limit the privileges of running components or the delegated privileges for human bearers of the AppCred. The fact that EC2 credentials can be used to -work around an regain the privileges of the user who created the original +work around and regain the privileges of the user who created the original AppCred is a serious issue, as it breaks the principle of least privileges and may weaken or break security models for applications or delegated authorizations. Note that this vulnerability does not allow to escalate privileges further -than the original AppCred creators privileges and does require the attacker +than the original AppCred creator's privileges and does require the attacker to get access to the limited AppCred in the first place. ## Embargo @@ -88,4 +88,5 @@ SCS security contact is [security@scs.community](mailto:security@scs.community), ## Version history +- Typo fixes and yaook link, v1.0, 2026-04-09, xx:xx CEST - Initial draft, v0,9, 2026-04-08, 13:45 CEST