DokuWiki: Recently Opened Tasks

[issue-open]: Search in Media Manager loses paramteres

annda — Tue, 31 Mar 2026 10:10:06 +0000

### The problem

I am using Media Manager from within a plugin (tested with struct and prosemirror) to select media files. Those plugins insert the media into their own input fields, so the provide extra request parameters to the media manager, including a callback.

The struct requests looks like this: `https://example.com/lib/exe/mediamanager.php?ns=test%3Aplugins&edid=struct__69cb958ab7126&onselect=insertStructMedia`

But then the request parameters are purged by [in the search form](https://github.com/dokuwiki/dokuwiki/blob/b1f32137ecbabcc1258c011d36e7b5a90560efd0/inc/media.php#L1638)

As a result, the plugin-specific context is lost and the struct callback is never called. So media syntax is simply inserted into the editor textarea (if available), since it's a fallback.

If I am reading [media.js](https://github.com/dokuwiki/dokuwiki/blob/b1f32137ecbabcc1258c011d36e7b5a90560efd0/lib/scripts/media.js#L271) correctly, this is where `edid` and `onselect` are handled. But they are missing after search.

This behavior was originally reported in: https://github.com/cosmocode/dokuwiki-plugin-struct/issues/752

Prosemirror editor is also affected. Because is replaces the syntax editor textarea, nothing at all is inserted after executing media search.

### Version of DokuWiki

2025-05-14b "Librarian" and master

### PHP Version

8.4

### Webserver and version of webserver

Nginx

### Browser and version of browser, operating system running browser

_No response_

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: Parser Error: Greedy matching of double curly braces {{ across table cells/structures mangles content

eduardomozart — Mon, 23 Mar 2026 18:49:59 +0000

### The problem

There is an issue with how the DokuWiki parser handles double curly braces `{{` when they are used as literal text inside a table cell. If a subsequent table or section contains a legitimate image link `{{image.png}}`, the parser incorrectly pairs the first opening `{{` with the final `}}` of the image, treating all intermediate content (including table markup) as part of a media link.

**Steps to Reproduce**
Input the following DokuWiki markup:

```
| Cell 1 | This is a macro: {{macro}.function()} |
| Cell 2 | Normal text |

Sample text

| Image Cell | {{:wiki:image.png}} |
```

**Expected Behavior**
The parser should ideally recognize that `{{macro}.function()}` is not a valid image/media syntax or, at the very least, not allow media tags to span across table cell boundaries (`|`).

**Actual Behavior**
The renderer produces a broken `` tag starting from the first `{{` and only closing it at the end of the second table. This results in the following corrupted HTML output:

```html
This is a macro: ... content ... | {{:wiki:image.png
```

This effectively "swallows" the table structure and turns technical documentation into a giant, broken hyperlink.

**Workaround**
The current way to fix this is to manually escape the opening braces:
```
**{macro6}**=%%{{%%macro}.function()}
```

### Version of DokuWiki

2025-05-14 "Librarian"

### PHP Version

8.4

### Webserver and version of webserver

Apache 2.4 on Debian GNU/Linux 13 (trixie)

### Browser and version of browser, operating system running browser

Chrome 146.0.7680.81 on Windows 11

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: PHP Type Juggling in Session Authentication

splitbrain — Sun, 22 Mar 2026 18:08:55 +0000

This was reported by @morimori-dev via email

## Summary

* Type: Authentication Bypass via Type Juggling (CWE-697)
* Severity: Medium (CVSS 5.3)
* File: inc/auth.php, lines 340-342

The session authentication check uses loose comparison (==) instead of strict comparison (===) for SHA1 password hash, username, and browser UID validation. PHP type juggling allows "magic hash" values (SHA1 hashes starting with 0e followed by only digits) to be considered numerically equal.

## Vulnerable Code
```php
// inc/auth.php lines 340-342
($session['user'] == $user) && // loose comparison
($session['pass'] == sha1($pass)) && // loose comparison — TYPE JUGGLING RISK
($session['buid'] == auth_browseruid()) // loose comparison
```

## Proof of Concept

Known SHA1 magic hashes exist:

sha1("aaroZmOk") = 0e66507019969427134894567494305185566735
sha1("aaK1STfY") = 0e76658526655756207688271159624026011393
sha1("aaO8zKZF") = 0e89257456677279068558073954252716165668

In PHP: "0e66507..." == "0e76658..." evaluates to 0 == 0 → TRUE

If both $session['pass'] and sha1($pass) happen to be magic hashes, the authentication check passes regardless of the actual password value.

## Impact

Authentication bypass: Under specific conditions (both session hash and cookie hash are magic hashes), an attacker's session validation succeeds without knowing the correct password

Probability: Low per-user (~1 in 10^8 for SHA1), but increases with the number of users/installations

## Suggested Fix

```
// Change == to === on lines 340, 341, 342:
($session['user'] === $user) &&
($session['pass'] === sha1($pass)) &&
($session['buid'] === auth_browseruid())
```

[issue-open]: [Bug] Incorrect anchor redirect after renaming a section heading during a section edit

eduardomozart — Mon, 02 Mar 2026 15:56:14 +0000

### The problem

When editing a specific section of a page (using the section edit button) and changing the heading of that section, saving the page redirects the user to the old section anchor instead of the newly updated one. Because the old anchor no longer exists, the browser does not scroll to the edited section.

### Steps to Reproduce
1. Create a new page (or open an existing one) and add a heading, for example: ``== Section 1 ==``. Save the page.
2. Click the **Edit** button specifically for that section ("Section 1").
3. In the editor, change the heading text to something else, for example: ``== Section 2 ==``.
4. Click **Save**.

### Expected Behavior
After saving, DokuWiki should redirect the browser to the newly generated anchor corresponding to the updated heading (e.g., ``doku.php?id=page_name#section_2``). The page should scroll directly to the newly renamed section.

### Actual Behavior
DokuWiki redirects the browser to the old anchor (e.g., ``doku.php?id=page_name#section_1``). Since "Section 1" no longer exists, the page simply loads at the top, and the user loses their place in the document.

### Additional Context
It appears the redirect anchor is being passed from the initial state of the section edit form (likely hidden input fields) and isn't being dynamically recalculated based on the newly saved content before triggering the redirect.

### Version of DokuWiki

2025-05-14 "Librarian"

### PHP Version

8.4

### Webserver and version of webserver

Apache 2.4 on Debian 13 (Trixie)

### Browser and version of browser, operating system running browser

Chrome 145.0.7632.117 on Windows 11

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```

[issue-open]: New Extension Manager is missing the enabled/disabled filter checkboxes

fthommen — Thu, 12 Feb 2026 15:54:10 +0000

### The problem

After a recent upgrade to DokuWiki 2025-05-14b "Librarian" (from Kaos), the Extension Manager lost the previously present checkboxed filters for enabled and disabled extensions.
The controls used to be here:

Now they are gone:

Not having these controls makes the management of plugins hard, especially if there are many installed but disabled plugins, which can be for various reasons. Greying out disabled plugins in the list is not sufficient and forces the Wiki administrator to optically browse the complete list to find enabled or disabled plugins.

I would see this as an UI bug

### Version of DokuWiki

2025-05-14b "Librarian"

### PHP Version

8.2.29

### Webserver and version of webserver

NGINX 1.22.1 on Debian 12 "bookworm"

### Browser and version of browser, operating system running browser

Firefox 147.0.3 (aarch64) and Google Chrome 144.0.7559.133 (arm64) on macOS 15.7.3 "Sequoia" / Firefox 140.7.0esr on Debian 12 "bookworm"

### Additional environment information

_No response_

### Relevant logs and/or error messages

```text

```