louislam / uptime-kuma

📑 I have found these related issues/pull requests

I did not find any related issues

🛡️ Security Policy

I agree to have read this project Security Policy

Description

uptime-kuma/server/socket-handlers/status-page-socket-handler.js

Lines 139 to 157 in dbbc79a

    
           if (imgDataUrl.startsWith("data:")) { 
        
               if (! imgDataUrl.startsWith(header)) { 
        
                   throw new Error("Only allowed PNG logo."); 
        
               } 
        
               const filename = `logo${statusPage.id}.png`; 
        
               // Convert to file 
        
               await ImageDataURI.outputFile(imgDataUrl, Database.uploadDir + filename); 
        
               config.logo = `/upload/${filename}?t=` + Date.now(); 
        
           } else { 
        
               config.icon = imgDataUrl; 
        
           } 
        
           statusPage.slug = config.slug; 
        
           statusPage.title = config.title; 
        
           statusPage.description = config.description; 
        
           statusPage.icon = config.logo;

config.icon is never again referenced, only config.logo

👟 Reproduction steps

write to the status page socket handler with a payload like:

{
    "icon": "/path/to/an/icon.svg"
}

or similar.

👀 Expected behavior

Status page should use provided icon.

😓 Actual Behavior

Status page keeps using whatever icon it is already using

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

Debian bookworm aarch64

🌐 Browser

Google Chrome 124.0.6367.119

🖥️ Deployment Environment

Runtime: Docker 20.10.21 / nodejs 20
Database: sqlite/embedded
Filesystem used to store the database on: Debian/ext4 SSD
number of monitors: 1

📝 Relevant log output

No response

Yes that is a bug.
Thanks for digging into the code. Would you like to provide a PR => be attributed with this fix?
I am wondering: How did you come across this?

I have a PR almost ready, I'm just currently confirming on my patched local that it's possible to use the URL variant at all.

Assuming I can work out some CORS issues, then I'm expecting I can provide a simple one-liner.

As to how I came across it: I am automating a from-scratch status page setup, so the UI-driven upload flow is a no-go for me. I also don't really like the base64 upload because then I have to pull the current image and check if the contents match since I want to report whether I am changing the icon. I'd rather use either a cross-origin URL or a path relative to the data volume (I'm using the docker deployment variant).

I don't care about the attribution though; this is not my personal account

Confirmed that things work fine if I do this simple fix: #4750

	if (imgDataUrl.startsWith("data:")) {
	if (! imgDataUrl.startsWith(header)) {
	throw new Error("Only allowed PNG logo.");
	}

	const filename = `logo${statusPage.id}.png`;

	// Convert to file
	await ImageDataURI.outputFile(imgDataUrl, Database.uploadDir + filename);
	config.logo = `/upload/${filename}?t=` + Date.now();

	} else {
	config.icon = imgDataUrl;
	}

	statusPage.slug = config.slug;
	statusPage.title = config.title;
	statusPage.description = config.description;
	statusPage.icon = config.logo;

`saveStatusPage` socket handler does not use `icon` specified in payload if not base64-encoded