Remediation to a software vulnerability can be accomplished either by the developer who introduced it or by a different one. In this context, we refer to a self-fixed vulnerability when the fixing is carried out by the developer who introduced it. Previous research demonstrated that a developer who introduces a bug is also the best candidate to fix it. However, as vulnerabilities conceptually differ from non-security bugs and specific skills and knowledge are required for solving them, it is unclear if the previous finding also applies to vulnerabilities or specific vulnerability types. To fill this gap, in this paper, we investigate the diffusion of self-fixed vulnerabilities within software projects, the types of vulnerabilities that are more prone to self-fixing, and the time required to solve self-fixed vulnerabilities compared to non-self-fixed ones. Specifically, we analyzed 1,752 commits related to C and PHP open-source projects aimed at fixing (or self-fixing) vulnerabilities spanning 17 different types of software weaknesses. The results of our study show that 20.55% of the considered vulnerabilities in C projects and 36.46% of the considered vulnerabilities in PHP projects are self-fixed. In addition, the average remediation time of self-fixed vulnerabilities is generally shorter than non-self-fixed ones. In particular, in C projects, self-fixed integer overflow vulnerabilities are patched about 5 times shorter than non-self-fixed ones, while vulnerabilities related to improper calculation or conversion of numbers are generally fixed faster by other developers. Similarly, in PHP projects, CSRF vulnerabilities tend to be patched in a shorter time when they are self-fixed, while unauthorized access vulnerabilities are likely repaired faster by other developers. Our results can help both researchers and practitioners identifying the best candidates to solve specific vulnerability bugs.