WrapEarnPass created an issue (geany/geany#4643) I know [CVE-2025-56383](https://nvd.nist.gov/vuln/detail/CVE-2025-56383) isn't against Geany, but, Geany does have a plugin functionality similar to the one that was exploited. As noted in https://github.com/geany/geany/issues/4590, geany has a compiled in path to a user controlled directory. plugins.c@1156 ``` /* first load plugins in ~/.config/geany/plugins/ */ load_plugins_from_path(plugin_path_config); ``` A malicious actor could use this to convince a user to run a malicious plugin. Even though by default geany does not load any enumerated plugins, geany's plugin load is config controlled, so a malicious process could drop the plugin in the user controlled folder, and edit geany's config state to enable the plugin.
I have two proposals to address this in Geany. 1. prevent geany from attempting to load any plugins other than from the system path. 2. sign each geany-plugin(dll/so) for all platforms. Linux does not provide a native check-then-load for shared objects (.so). Windows has a [/INTEGRITYCHECK ](https://learn.microsoft.com/en-us/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170) flag. Mac has [codesign](https://ss64.com/mac/codesign.html) Both the windows and mac signatures may require certificates from those platforms, leading to additional management overhead, and no way for repackagers like msys2, brew, debian, etc to provide uniform packages. geany could use gpg detached signatures instead. This will require linking geany against gpg, and compiling the gpg public key used to sign geany-plugins into the geany binary. Upon startup, geany's normal plugin enumeration would run, and if a enumerated plugin is missing its signature or if the signature does not validate, geany would skip the plugin similarly to how it skips a plugin with an invalid ABI. geany-plugins already has an exemplar for gpg use cross platform (GeanyPG), so gpg should be available on all supported platforms. This is not perfect, and a TOCTOU race could allow a malicious process to flip the binary between validation and load. I would also advise against allowing a runtime or configtime flag to disable the signing check, as a malicious actor or process could engineer their way into getting a user to disable it, but I understand that it may be more user friendly for people who develop their own plugins to not have to recompile geany in order to have a usable plugin. If there is any interest, I wouldn't mind attempting the implementation. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/4643 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/[email protected]>
