Skip to content

Commit 692152f

Browse files
garloffgarloff
committed
Merge branch 'main' into staging
Signed-off-by: Kurt Garloff <kurt@garloff.de>
2 parents f0e3115 + 45eac80 commit 692152f

14 files changed

Lines changed: 1198 additions & 718 deletions

‎blog/2026-01-22-introducing-docs-blog.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ with distinct goals:
3434
## Blog articles
3535

3636
Blog articles with technical content relating to a specific implementation (or a set
37-
of implementations) are not a great fit for Forum's web site.
37+
of implementations) are not a great fit for the general web site.
3838
The good news is that the SCS project's rich
3939
[Documentation site](https://docs.scs.community/) is architected in a way that
4040
it assembles documentation from various places. Unlike the Forum, it does not need

‎blog/2026-01-23-cve-2026-22797.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,7 @@ paste.filter_factory = keystonemiddleware.auth_token:filter_factory
107107
- [ALASCA](https://alasca.cloud/) has issued an
108108
[advisory for yaook](https://lists.alasca.cloud/hyperkitty/list/yaook@lists.alasca.cloud/thread/Q2GZ7PNXHJ7YHRDALKXTHZMTHS7PM5NE/)
109109
basically stating that it's not really possible to use yaook in a way that it would be affected.
110-
- [OSISM](https://osism.tech/) has published an
110+
- [OSISM](https://osism.cloud/) has published an
111111
[advisary for OSISM](https://osism.tech/docs/appendix/security/ossa-2026-001/)
112112
with more details how to get a fixed keystone container deployed in case you
113113
have manually enabled such oauth2 tokens.

‎blog/2026-02-17-cve-2026-24708.md‎

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
---
2+
title: CVE-2026-24708 OpenStack Missing image format validation on resize
3+
authors: [garloff]
4+
slug: openstack_image_resize_missing_validation_cve_2026_24708
5+
tags: [security, openstack, cve]
6+
---
7+
8+
## The vulnerability
9+
10+
OpenStack supports a variety of image formats to ease migration from other
11+
virtualization platforms. The qemu-img tools are used to deal with these
12+
images. Unfortunately, OpenStack developers had to learn that qemu-img is
13+
not as robust as expected when dealing with untrusted images. This has lead to
14+
[CVE-2022-47951](https://sovereigncloudstack.org/community_blog/sovereign-cloud-stack-security-advisory-vmdk-image-processing-cve-2022-47951/)
15+
and
16+
[CVE-2024-32498](https://sovereigncloudstack.org/community_blog/scs-security-advisory-on-arbitrary-file-access-through-qcow2-external-data-file-cve-2024-32498/)
17+
and
18+
[CVE-2024-40767](https://sovereigncloudstack.org/community_blog/scs-security-advisory-on-incomplete-qcow2-and-vmdk-image-handling-protections-cve-2024-40767/)
19+
.
20+
21+
Analyzing all potentially vulnerable code paths, at least one had been overlooked
22+
by developers before: When resizing VMs in Nova to a flavor with a new root
23+
disk/ephemeral disk size, and Nova's flat image backend is in use, `qemu-img` is called
24+
on the backing image file without an explicit format specifier, opening up the
25+
possibility to overwrite files on the host system by writing a malicious QCOW header
26+
to a root or ephemeral disk.
27+
28+
This vulnerability has been assigned [CVE-2026-24708](https://nvd.nist.gov/vuln/detail/CVE-2026-24708).
29+
30+
## Impact on the SCS software ecosystem
31+
32+
By default, Nova uses cow images, i.e. `use_cow_images` in `nova.conf` defaults
33+
to `True`.
34+
35+
This value is not changed in either [OSISM](https://osism.tech/) nor
36+
[yaook](https://alasca.cloud/en/projects/yaook/), so neither of these implementations
37+
is affected by the vulnerability. Operators need to have made a deliberate effort
38+
to override this setting.
39+
40+
_If this setting is set to `False`, authenticated users may write malicious QCOW2
41+
or VMDK headers to the disk and then use the VM resize to overwrite files on the host
42+
with zeros, causing failure of the compute host._
43+
44+
The overwriting of arbitrary files with zeroes has been reproduced using QCOW
45+
headers; it may be possible to do more controlled damage (e.g. writing non-zeros)
46+
using more exotic features in e.g. the VMDK headers and this way cause more than
47+
a Denial-of-Service but gain privileges or exfiltrate data.
48+
49+
Operators that are using `use_cow_images=False` in their nova config are
50+
advised to apply the fixes urgently or change this setting temporarily.
51+
52+
## Embargo
53+
54+
The issue has been reported to the OpenStack Vulnerability Management Team in
55+
private. The reporters and upstream developers have worked together to address
56+
the issue with fixes and an embargo date
57+
has been set to Tuesday, 2026-02-17, 15:00 UTC (16:00 CET). At this point in
58+
time, the patches get merged and the OpenStack Security Advisory
59+
[OSSA-2026-002](https://security.openstack.org/ossa/OSSA-2026-002.html) is
60+
published. The issue is tracked in OpenStack issue
61+
[#2137507](https://bugs.launchpad.net/nova/+bug/2137507), which should become
62+
publically accessible after the lift of the embargo and the publication
63+
of this advisory.
64+
65+
Under the used responsible disclosure approach, the information was shared with
66+
a select group of trustable users of OpenStack, so they can prepare updates and
67+
protect their user data in time for the publication.
68+
69+
## Mitigation and Fixes
70+
71+
The temporary fix for this issue is to avoid `use_cow_images=false` in
72+
`/etc/nova.conf`. This will stop this issue from being triggered.
73+
Alternatively, full glance format-inspector protection should help against
74+
this.
75+
76+
There are patches from the upstream OpenStack developers available. They work
77+
by passing `-f raw` to `qemu-img` when a resize happens with raw images and
78+
`-f qcow2` for QCOW2 images. Other images are disallowed for resizing.
79+
80+
The SCS ecosystem software providers will provide fixed nova-compute images and
81+
installation instructions here as soon as the updated images are available:
82+
83+
- [yaook](https://yaook.cloud/security-advisories-cve-2026-24708)
84+
- [OSISM](https://osism.tech/docs/appendix/security/ossa-2026-002)
85+
86+
## Thanks
87+
88+
The author would like to thank Dan Smith, Jay Faulkner, Sylvain Bauza,
89+
Melanie Witt, and Jeremy Stanley for reporting, reproducing, fixing
90+
and coordinating this issue.
91+
92+
<!-- BROKEN
93+
## Sovereign Cloud Stack Security Contact
94+
95+
SCS security contact is <mailto:security@scs.community>, as published on
96+
<https://sovereigncloudstack.org/.well-known/security.txt>.
97+
-->
98+
99+
## Version history
100+
101+
- Mention glance format-inspector protection, v1.0, 2026-02-17, 15:30 CET.
102+
- Typos fixed, v0.6, 2026-02-16, 15:45 CET.
103+
- Initial Draft, v0.5, 2026-02-16, 15:00 CET.

‎blog/2026-04-08-cve-2026-33551.md‎

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
---
2+
title: CVE-2026-33551 OpenStack privilege escalation with EC2 credentials from Application Credentials
3+
authors: [garloff]
4+
slug: openstack_privescal_ec2_creds_from_appcreds_cve_2026_33551
5+
tags: [security, openstack, cve]
6+
---
7+
8+
## The vulnerability
9+
10+
OpenStack allows the creation of Application Credentials to give its bearer
11+
access to a project with the privileges of the user who created the AppCreds.
12+
Application Credentials can have a limited lifetime and can be revoked. They
13+
can also be _restricted_ (which means that they can not be used to create
14+
additional application credentials) or can be assigned roles with lower
15+
privileges, limiting the privileges that the bearer has.
16+
17+
When AppCreds are used to create EC2 credentials, keystone failed to
18+
require _unrestricted_ AppCreds and failed to require the member role,
19+
giving AppCreds that are _restricted_ or that have limited roles the
20+
ability to create EC2 credentials with the full privileges of the user
21+
who created the AppCred.
22+
23+
This issue was reported by Maxence Bornecque from Orange Cyberdefense CERT
24+
Vulnerability Intelligence Watch Team and has been assigned
25+
[CVE-2026-33551](https://nvd.nist.gov/vuln/detail/CVE-2026-33551).
26+
27+
## Impact on the SCS software ecosystem
28+
29+
This issue affects OpenStack environments that allow the creation of EC2
30+
style credentials, which is typically used for S3 access or EC2 compatibility.
31+
This is typically the case for SCS clouds, as S3 compatibility is a requirement.
32+
33+
While creating AppCreds with roles with lower privileges is not a very common
34+
use case, it is supported by OpenStack clouds and is actually a good practice
35+
to limit the privileges of running components or the delegated privileges for
36+
human bearers of the AppCred. The fact that EC2 credentials can be used to
37+
work around and regain the privileges of the user who created the original
38+
AppCred is a serious issue, as it breaks the principle of least privileges
39+
and may weaken or break security models for applications or delegated
40+
authorizations.
41+
42+
Note that this vulnerability does not allow to escalate privileges further
43+
than the original AppCred creator's privileges and does require the attacker
44+
to get access to the limited AppCred in the first place.
45+
46+
## Embargo
47+
48+
The issue has been reported to the OpenStack Vulnerability Management Team in
49+
private. The reporters and upstream developers have worked together to address
50+
the issue with fixes and an embargo date
51+
has been set to Tuesday, 2026-04-07, 15:00 UTC (17:00 CEST). At this point in
52+
time, the patches get merged and the OpenStack Security Advisory
53+
[OSSA-2026-005](https://security.openstack.org/ossa/OSSA-2026-005.html) is
54+
published. The issue is tracked in OpenStack issue
55+
[#2142138](https://bugs.launchpad.net/nova/+bug/2142138), which should become
56+
publically accessible after the lift of the embargo and the publication
57+
of this advisory.
58+
59+
Under the used responsible disclosure approach, the information was shared with
60+
a select group of trustable users of OpenStack, so they can prepare updates and
61+
protect their user data in time for the publication.
62+
63+
## Mitigation and Fixes
64+
65+
The temporary fix for this issue would be to disable the creation of EC2
66+
credentials which however would prevent to enable new S3 access.
67+
68+
There are patches from the upstream OpenStack keystone developers available.
69+
They add a check in the EC2 credential creation path that requires the
70+
AppCred to be unrestricted and to have at least member access to the project.
71+
72+
The SCS ecosystem software providers provide fixed keystone images and
73+
installation instructions here as soon as the updated images are available:
74+
75+
- [OSISM](https://osism.tech/docs/appendix/security/ossa-2026-005)
76+
- [yaook](https://yaook.cloud/security-advisories-cve-2026-33551)
77+
78+
## Thanks
79+
80+
The author would like to thank Maxence Bornecque, Grzegorz Grasza,
81+
Douglas Mendizabal, Artem Goncharov, and Jeremy Stanley for reporting,
82+
fixing and coordinating this issue.
83+
84+
## Sovereign Cloud Stack Security Contact
85+
86+
SCS security contact is [security@scs.community](mailto:security@scs.community), as published on
87+
[https://sovereigncloudstack.org/.well-known/security.txt](https://sovereigncloudstack.org/.well-known/security.txt).
88+
89+
## Version history
90+
91+
- Typo fixes and yaook link, v1.0, 2026-04-09, 10:30 CEST
92+
- Initial draft, v0,9, 2026-04-08, 13:45 CEST

‎community/cloud-resources/cloud-resources.md‎

Lines changed: 41 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4,15 +4,47 @@ This document gives an overview of the test and development cloud resources curr
44

55
## How to request cloud resources
66

7-
To request access to an existing project, please contact the responsible community member. To apply for a new project, please create a pull request against this document (leave `Unique Identifier` blank) and assign it to the particular CSP team (e.g. @SovereignCloudStack/plusserver, @SovereignCloudStack/wavecon, ...)
7+
To request access to an existing project, please contact the responsible community member as described below.
88

9-
## plusserver (SCS2)
9+
## SCS Hardware Landscape
10+
11+
For access to the SCS Hardware Landscape, please send an email to the [SCS Project Board](https://docs.scs.community/community/governance/project-board) at [project-board@lists.scs.community](mailto:project-board@lists.scs.community).
12+
Please note that the email address you provide will also be used for your login details and further communication.
13+
The email should contain the following information:
14+
15+
- Short summary of the intended usage of the SCS Hardware Landscape
16+
- link to PR for [SSH access](#ssh-access)
17+
- OPTIONAL: if needed, information about the SSH key to be used
18+
- link to PR for [VPN access](#vpn-access)
19+
20+
The SCS Project Board will assess the request based on the intended usage and available capacity and will then take a decision in a timely manner.
21+
22+
### SSH Access
23+
24+
To request SSH access, [create a PR by following the steps 1 and 2](https://github.com/SovereignCloudStack/hardware-landscape/blob/main/documentation/System_Runbooks.md#manage-ssh-access-and-adminstrative-permissions).
25+
Assign the PR to the members of the SCS Project Board.
26+
Please note to specify your GitHub handle and that your GitHub SSH key (`https://github.com/<GITHUB_HANDLE>.keys`) will be used by default unless otherwise specified in your initial email request.
27+
Once the PR has been accepted, [configure your SSH access](https://github.com/SovereignCloudStack/hardware-landscape/blob/main/documentation/System_Usage.md#configure-ssh-access).
28+
29+
### VPN Access
30+
31+
To request VPN access, [create a PR by following the steps 1 to 3](https://github.com/SovereignCloudStack/hardware-landscape/blob/main/documentation/System_Usage.md#configure-vpn-access).
32+
Assign the PR to the members of the SCS Project Board.
33+
Once the PR has been accepted, [configure your VPN access by following the steps 5 to 7](https://github.com/SovereignCloudStack/hardware-landscape/blob/main/documentation/System_Usage.md#configure-vpn-access).
34+
35+
### SCS Hardware Landscape Usage
36+
37+
More information on how to use the Hardware Landscape can be found [here](hardware-landscape.md).
38+
39+
## SCS2 @ plusserver
1040

1141
SCS2 is the successor to gx-scs (or SCS1), which no longer exists.
1242

43+
To apply for a new project, please create a pull request against this document (leave `Unique Identifier` blank) and assign it to the CSP team @SovereignCloudStack/plusserver.
44+
1345
### SCS2 Usage
1446

15-
A brief guide on how to use the resources provided by plusserver GmbH can be found [here](plusserver-gx-scs.md)
47+
A brief guide on how to use the resources provided by plusserver GmbH can be found [here](plusserver-gx-scs.md).
1648

1749
### SCS2 Users
1850

@@ -65,6 +97,12 @@ Service users will have their default_project_id set to a specific project and w
6597

6698
## Wavecon
6799

100+
To apply for a new project, please create a pull request against this document (leave `Unique Identifier` blank) and assign it to the CSP team @SovereignCloudStack/wavecon.
101+
102+
### Wavestack Usage
103+
104+
A brief guide on how to use the resources provided by Wavecon GmbH can be found [here](wavestack.md).
105+
68106
### Wavestack Service Users
69107

70108
| Unique Identifier | Service User Name | Full Access on | Community Contact | Description | Needed until |

‎community/cloud-resources/hardware-landscape.md‎

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
---
2+
title: Getting Started with SCS Hardware Landscape
3+
version: 2025-12-19
4+
author: Marvin Frommhold
5+
---
6+
7+
## Getting Started with the SCS Hardware Landscape
8+
9+
The SCS Hardware Landscape is a publicly accessible training and demonstration environment of the SCS reference implementation on hardware operated by the Forum SCS-Standards.
10+
Interested parties, for example customers who want to test their software for SCS compatibility, can get access to it.
11+
It is currently running at a colocation of ScaleUp Technologies.
12+
13+
### URLs for accessing the SCS Hardware Landscape
14+
15+
To access the SCS Hardware Landscape refer to the [list of environment links](https://github.com/sovereignCloudStack/hardware-landscape?tab=readme-ov-file#environment-links) in the SCS Hardware Landscape repository.
16+
17+
### Authentication (UI)
18+
19+
For the login you will need your email address you provided to the Project Board and your password.
20+
21+
### Documentation of the SCS Hardware Landscape
22+
23+
A brief documentation of the SCS Hardware Landscape can be found on the ["Hardware-Landscape turnkey solution page"](https://docs.scs.community/docs/turnkey-solution/hardware-landscape) and in the [SCS Hardware Landscape repository](https://github.com/SovereignCloudStack/hardware-landscape).

‎community/cloud-resources/plusserver-gx-scs.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
title: Getting Started Gaia-X Demonstrator @ plusserver
2+
title: Getting Started with SCS2 @ plusserver
33
version: 2022-12-22
44
author: Ralf Heiringhoff, Mathias Fechner
55
---

‎community/governance/project-board.md‎

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -9,10 +9,11 @@ For the term 2026 the project board consists of:
99

1010
Spokesperson: Kurt Garloff, @garloff
1111

12-
| Name, Firstname | Github Handle | E-Mail | Remark |
13-
| ----------------------- | ---------------------------------------------- | ----------------------------------------------------------- | ------------------------------ |
14-
| Bayr, Michael | [@michaelbayr](https://github.com/michaelbayr) | [mb@artcodix.com](mailto:mb@artcodix.com) | Elected by Community |
15-
| Garloff, Kurt | [@garloff](https://github.com/garloff) | [scs@garloff.de](mailto:scs@garloff.de) | Elected by Community |
16-
| Klare, Jan | [@jklare](https://github.com/jklare) | [klare@osism.tech](mailto:klare@osism.tech) | Elected by Community |
17-
| Kronlage-Dammers, Felix | [@fkr](https://github.com/fkr) | [fkr@osb-alliance.com](mailto:fkr@osb-alliance.com) | Represents Forum SCS-Standards |
18-
| Schoone, Jan | [@jschoone](https://github.com/jschoone) | [jan.schoone@uhurutec.com](mailto:jan.schoone@uhurutec.com) | Elected by Community |
12+
| Name, Firstname | Github Handle | E-Mail | Remark |
13+
| ----------------------- | ---------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------- |
14+
| Bayr, Michael | [@michaelbayr](https://github.com/michaelbayr) | [mb@artcodix.com](mailto:mb@artcodix.com) | Elected by Community |
15+
| Garloff, Kurt | [@garloff](https://github.com/garloff) | [scs@garloff.de](mailto:scs@garloff.de) | Elected by Community |
16+
| Kemper, Janis | [@janiskemper](https://github.com/janiskemper) | [janis.kemper@syself.com](mailto:janis.kemper@syself.com) | Deputy Representative Forum SCS-Standards |
17+
| Klare, Jan | [@jklare](https://github.com/jklare) | [klare@osism.tech](mailto:klare@osism.tech) | Elected by Community |
18+
| Kronlage-Dammers, Felix | [@fkr](https://github.com/fkr) | [fkr@osb-alliance.com](mailto:fkr@osb-alliance.com) | Represents Forum SCS-Standards |
19+
| Schoone, Jan | [@jschoone](https://github.com/jschoone) | [jan.schoone@uhurutec.com](mailto:jan.schoone@uhurutec.com) | Elected by Community |

0 commit comments

Comments
 (0)