This CVE seems invalid

[matthijskooijman]

One of the hamster upstream maintainers here. We've heard about this issue through Debian and investigated. As far as we can tell, this is not actually a security issue in hamster (and probably not a security issue at all).

If you disagree, please elaborate on the issue.

If you agree, can we update the CVE accordingly?

[matthijskooijman]

See also projecthamster/hamster#750 for more in-depth discussion.

[BrunoTeixeira1996]

@matthijskooijman I've read all the other posts you mentioned and I disagree ...
From a security point of view, every software that generates some kind of spreadshet, excel, tsv, etc needs to properly escape every possible malicious symbols.

The problem here is that hamster exports (note that you said [CVE-2023-36250] Arbitrary code exection possible through CSV import and this is wrong) the activity without any proper escaping. Meaning that I can create localy a malicious payload and send that to any victim. If that victim has formulas enabled that payload will get executed.

So if YOUR APPLICATION is creating a csv, tsv file you are responsible for escaping malicious payloads ...
Why would you want to use the activity field as a injection too? If that has no use case you should consider my point again

[rhertzog]

From a security point of view, every software that generates some kind of spreadshet, excel, tsv, etc needs to properly escape every possible malicious symbols.

Can you explain how you achieve that?

AFAIK TSV and CSV are pure data file formats. They do not support formulas and anything else. If you use a spreadsheet software that does interpret some data as formula, then the issue is in the spreadsheet software, not in the software that generates the CSV/TSV.

To me this CVE claim seems ill-founded.

[BrunoTeixeira1996]

From a security point of view, every software that generates some kind of spreadshet, excel, tsv, etc needs to properly escape every possible malicious symbols.

Can you explain how you achieve that?

AFAIK TSV and CSV are pure data file formats. They do not support formulas and anything else. If you use a spreadsheet software that does interpret some data as formula, then the issue is in the spreadsheet software, not in the software that generates the CSV/TSV.

If you can use a spreadsheet software to show csv/tsv data and that data can be a formula you have your answer there. I understand your point of view, however if your software is providing and opening an excel on export, your software needs to sanitize the user input

To me this CVE claim seems ill-founded.

I will not argue with that, thats your opinion, however MITRE reviewed my submission and agreed that this is indeed a vulnerability. Wether you find this is valid or no its up to you. The risk is low because there's need to be some user interaction, however there's still risk. This is where I stand.