The SOGO Add Script to Individual Pages Header Footer WordPress plugin through 3.9 does not sanitise or escape the custom header/footer script values saved from its post metabox, and does not restrict them to users with the unfilteredhtml capability, allowing users with contributor-level access and above to store JavaScript that executes in the browser of any administrator who reviews the post and of any visitor once the post is published.

Last updated 6 July 2026

A SQL injection vulnerability in SOGo before 5.12.7 allows authenticated users to execute arbitrary SQL statements via the search parameter of the allContactSearch endpoint.

A SQL injection vulnerability in SOGo before 5.12.7 allows authenticated users to execute arbitrary SQL statements via the newPassword parameter in the password change functionality.

Last updated 6 July 2026

Last updated 6 July 2026

SOGo before 5.12.7, when PostgreSQL or MariaDB is used, and cleartext passwords are stored, allows SQL injection. This is related to cpassword = '%@' in changePasswordForLogin.

An Insecure Direct Object Reference (IDOR) vulnerability was discovered in SOGo Webmail thru 5.6.0, allowing an authenticated user to send emails on behalf of other users by manipulating a user-controlled identifier in the email-sending request. The server fails to verify whether the authenticated user is authorized to use the specified sender identity, resulting in unauthorized message delivery as another user. This can lead to impersonation, phishing, or unauthorized communication within the system. NOTE: this is disputed by the Supplier because the only effective way to prevent this sender spoofing is on the SMTP server, not within a client such as SOGo.

Hi,

On Wed, Jul 02, 2025 at 07:01:52PM +0200, Stefan Bühler wrote: Hello,

I found a DoS bug in SOPE, the set of Objective-C frameworks powering SOGo [1].

It is way too easy to trigger with curl:

curl -d 'x=' 'https://.../SOGo/?x='

As far as I can tell all versions since SOGo-2.0.2 (2012-10-29) are affected.

Details

I found it inspecting multiple SOGo crashes triggered by someone hitting URLs like /OAHTML/BneViewerXMLService?bne:uueupload=TRUE with POST that my search engine associates with "Oracle E-Business Suite (EBS)".

The crash happens in NGHashMap.m line 790 [2], as root->last is NULL:

root->last->next = element;

NGHashMap maps a key to a single-linked list of values.

It turns out -[NGMutableHashMap addObjects:count:forKey:] is the only function maintaining the root->last pointer; everything else in this file doesn't touch it.

The SOPE request handling first parses the POST body for "formParameters", then clones that NGHashMap (the copied nodes have last == NULL), and then merges the query string parameters into it; if there is a duplicate key the bug triggers.

I'd like to point out that the linked-list implementation is quite bad. It wastes memory by using the same struct for the root node (with count and last metadata) and the member nodes, and seems to throw exceptions (e.g. when values are nil) but isn't exception safe (metadata isn't updated consistently).

See attached patch for an attempt to maintain the last pointer properly across all methods; it seems to work for me (on top of 5.8.0-1 in debian/bookworm); submitted to upstream in [4].

In the long run at least the linked-list implementation should probably be replaced by using some properly tested library.

The last handling was introduced in dfceefc 2012-10-15 [3], and I think it has been broken since then.

(I haven't actually tried to reproduce it with latest upstream, but I don't think any of the code has been touched in relevant ways.) FTR, CVE-2025-53603 has been assigned for this issue.

Regards, Salvatore

Hello,

I found a DoS bug in SOPE, the set of Objective-C frameworks powering SOGo [1].

It is way too easy to trigger with curl:

curl -d 'x=' 'https://.../SOGo/?x='

As far as I can tell all versions since SOGo-2.0.2 (2012-10-29) are affected.

Details

I found it inspecting multiple SOGo crashes triggered by someone hitting URLs like /OAHTML/BneViewerXMLService?bne:uueupload=TRUE with POST that my search engine associates with "Oracle E-Business Suite (EBS)".

The crash happens in NGHashMap.m line 790 [2], as root->last is NULL:

root->last->next = element;

NGHashMap maps a key to a single-linked list of values.

It turns out -[NGMutableHashMap addObjects:count:forKey:] is the only function maintaining the root->last pointer; everything else in this file doesn't touch it.

The SOPE request handling first parses the POST body for "formParameters", then clones that NGHashMap (the copied nodes have last == NULL), and then merges the query string parameters into it; if there is a duplicate key the bug triggers.

I'd like to point out that the linked-list implementation is quite bad. It wastes memory by using the same struct for the root node (with count and last metadata) and the member nodes, and seems to throw exceptions (e.g. when values are nil) but isn't exception safe (metadata isn't updated consistently).

See attached patch for an attempt to maintain the last pointer properly across all methods; it seems to work for me (on top of 5.8.0-1 in debian/bookworm); submitted to upstream in [4].

In the long run at least the linked-list implementation should probably be replaced by using some properly tested library.

The last handling was introduced in dfceefc 2012-10-15 [3], and I think it has been broken since then.

(I haven't actually tried to reproduce it with latest upstream, but I don't think any of the code has been touched in relevant ways.)

cheers, Stefan

[1] https://www.sogo.nu/ [2] https://github.com/Alinto/sope/blob/3146fbdb6ff3314e37e5c3682deeeef7d0f32064/sope-core/NGExtensions/NGHashMap.m#L790 [3] https://github.com/Alinto/sope/commit/dfceefcb141c1b31b26eea19ca07d3916d663315 [4] https://github.com/Alinto/sope/pull/69